Hacker News new | comments | ask | show | jobs | submit login
Show HN: Radi, my HTML5 content creation app (Mac) (radiapp.com)
297 points by pavlov on Dec 26, 2010 | hide | past | web | favorite | 38 comments

Radi is a side project of mine that has kept me occupied for the better part of 2010. I'm very happy to finally have it in a half-presentable state, just in time for 2011! What's that they say about the first release -- "if you're not embarrassed, you waited too long?" Well, this is that one for me :)

It's scary to put this app out there to the whole world in its current condition, but I feel like I've reached a dead-end.

There are too many directions in which this app could be developed. I need to cut down on the abstract ambition and start focusing on some real-world use cases.

For that, I desperately need your help! What's your biggest need in the world of HTML5 content creation? Do you see a path for this app to be developed into the tool that would fit your needs?

Thanks for any input, and (slightly prematurely) a great 2011 for everyone on HN! I appreciate this community enormously.


A few words about the technical details of this app...

Although the app targets HTML publishing, the compositing core doesn't actually use any kind of browser engine like WebKit. Instead, it's a node-based GPU-accelerated compositing system of my own devising. Layers and effects are rendered using OpenGL.

Because there's no browser engine, there's also no browser-style DOM available in Radi. I've written private implementations of the relevant JavaScript APIs, primarily Canvas. The JavaScript engine used is WebKit's JavaScriptCore, a.k.a. Nitro in its current accelerated incarnation.

The app is native Cocoa, but it's written in a way that's fairly portable. (From my other projects I already have a large part of the core ported to Windows+Direct3D.)

I won't lie, I'm having a hard time using this app. I spent awhile looking for a create keyframe buton and almost gave up before realizing how to do animations. I still don't know how to build custom shapes with curves or how to draw shapes that exist for a short duration. When I published the canvas element it didn't animate in the browser.

Clearly you've solved a lot of interesting technical problems, but I feel kinda clueless while using it. As far as I know the only people who use the flash authoring environment these days are advertisers and animators (or designers building content for flex apps). So if you want to focus this, I'd say go after those people. When people do make flash sites in the authoring environment they usually rely heavily on simple onclick and gotoandplay statements.

I'm impressed with what I see, but I don't know what problem has been solved.

Yeah, I completely see what you mean. That's pretty much what I meant by "abstract ambition" in my original post. I feel like I've spent a fair bit of time building modules that are generic enough to be the basis for a few different apps, but the whole doesn't yet do anything specific well enough.

That's why I felt like I need to release this sooner rather than later. It would be appealing to go on polishing the app for an imaginary customer who happens to be just like me (my other application, Conduit Live, went down that drain)... But it's healthier to face criticism and try to figure out if there's some potential customer group(s) out there that I didn't anticipate.

FWIW, I feel like there might be something interesting to be done in the intersection between realtime graphics and video on the web. Flash has a lot of cool technology, but nowadays you need to be a coder to take advantage of the new stuff like Pixel Bender shaders or the Alchemy compiler -- Adobe seems to have "outgrown" the designer audience who originally made Flash a success, and I think that's a mistake.

Re: your points about Radi -- there's a big hole in the <canvas> publishing functionality currently, it doesn't export all keyframes. Sorry about that, I'm hoping to fix that ASAP. The keyframing UI is not very well thought out, and needs a lot more work. To make polygon shapes, choose "Draw Shape" from the toolbar and click away in the viewer. There's no exposed way to limit the shapes' visibility in the timeline either (internally there's a concept of empty keyframes same as in Flash, but it's not in the UI).

I don't think it can be stressed enough how important it is to prevent feature creep while you still have the chance.

I can't imagine the repercussions of cutting down the program down the line after people have acquainted themselves with it - to the point of feeling completely entitled.

Aren't the side projects the real projects in the end? :)

I remember when we had to design a service and an interface for it in Flash in college. The university did not provide an Adobe license, so the license would run out right around the examinations, assuming you hadn't installed it earlier to play around with. They basically wink-wink-nudge-nudged people into pirating the whole thing.

Had we had something like this, things would have been so much easier in every conceivable way. Working with Adobe Flash was perhaps the worst experience of my time in college.

It's funny to think about sites like newgrounds.com and kongregate.com and how HTML5 might challenge the domination of Flash.

A truly incredible piece of software pavlov. Well done!

What does that phrase mean, "software pavlov"?

The OP's name is 'pavlov', and your parent should have included a comma.

Couldn't this be used as a replacement for Flash? I know one of your selling points is that you can do some rather amazing visual imagery without needing any programming skills; but what if you coupled a basic image/video/animation editor with scripting abilities (javascript)? You would have a nice alternative for tired-of-flash developers who create sites like the Droid product page, pretty much every movie landing page, and every video game product page. You know Adobe is already working on it, and Dreamweaver is already integrating HTML5. But build something on open standards, not tightly integrated to any one image/vector editing software, and you would have a strong market.

Why is there no browser engine? It would seem like your method of "writing my own of everything I need" doesn't really scale well to something like the entire browser stack. And it appears that WebKit should not be that hard to integrate (in the general case, not sure about this kind of authoring app).

You may have a good reason, I just can't think of it off the top of my head.

Well, of course the real reason is simply that I wanted to make use of the stuff that I already had written, which consisted primarily of a fast compositing engine with JavaScript hooks. (I'm not one of those people who want to start from scratch for each project.)

But I do think there is a solid case for this approach. Consider something like image filters and applying them to video. If the authoring UI were implemented in WebKit, I don't know how I could get realtime responsiveness for video manipulation. Now it's no problem in Radi because the rendering bottleneck to produce actual browser-playable <video> content only happens upon publishing.

Being on the native side gives me a theoretical edge when it comes to new browser features -- I'm thinking of something like visual effects which may be supported only by Mozilla but not WebKit, or vice versa. Not being married with a specific engine could be an advantage.

It's worth mentioning that Radi does actually use WebKit to render the content in HTML layers. So you can place custom HTML within a document, and it's rendered with browser-style text antialiasing within the app. (It's not dynamic, though -- just a snapshot of the HTML rendering.)

Looks awesome. Whats your email?

Ah, didn't see that. Thanks

There's a contact form at http://www.radiapp.com/radiapp/feedback/.

>Although the app targets HTML publishing, the compositing core doesn't actually use any kind of browser engine like WebKit. Instead, it's a node-based GPU-accelerated compositing system of my own devising. Layers and effects are rendered using OpenGL. ...private implementation of the [DOM javascript API] etc.

http://i.imgur.com/6BC1o.png Recoil/long-neck guy, a meme. Pardon the banality, but it's what I actually did when I was reading this.

You are one ridiculously industrious individual. Congrats, I can't wait to find an excuse to tinker with Radi. :)

First of all, when they come and offer you a pile of money (and they will), please insist on a clause that they release it. Someone may try to bury it.

Anyway, I had fun playing with it. The timeline gives me happy/terrifying Director/Flash flashbacks. I can't figure out how to make an animation cycle in the timeline (i.e. like a walk animation) without cheating & creating keyframes by moving stuff to a slightly different (x,y).

I also couldn't figure out how to script top-level elements (does everything need to be composited inside a cavas?). I added a number of "picture layer" objects that I wanted to move via keyboard control. I couldn't figure out how to put a script in the topmost layer to do this (nor could I see how to reference the sub-layers so that I could move them). I might have been fooling myself -- it looks so much like Flash or Director, that I expected to be able to write a top-level script that controls all of the sub-elements. If that's not possible due to the overall layer architecture, you should make that clear (by making the other scripting opportunities explicit when available).

A few quick suggestions:

- The "command line" input in the script editor is a great idea, like the "message window" of HyperCard or FaceSpan. I think you'd do well to make it its own window, and have the last result displayed underneath the input area (ala FaceSpan) so I don't have to wrap everything in sys.trace.

- Positioning elements via arrow keystrokes doesn't seem to work -- please implement bindings similar to Interface Builder (or FaceSpan) where modifier do useful things like snap to grid and stretch.

- JavaScript API reference menu item doesn't seem to work. I found it eventually (http://lacquer.fi/developer/conduit-js/#sys in case anyone else has the same problem).

Overall, it looks great. I can't wait to hard to believe you kept it quiet long enough to do all of this. Congratulations!

Thanks so much for the insightful comments!

I know what you mean by the happy/terrifying timeline :) I thought hard whether it would be misleading to make the timeline look so similar, especially when it doesn't have the same functionality at this point, and the quirkiness of Flash keyframing has been such a source of frustration to users. But I decided that the big elements need to have a certain familiarity in order to make the app's purpose more obvious at a glance. (I guess it would be the same if I was making a photo editor: there are some UI conventions that are clearly outdated but people expect them from years of Photoshopping.)

There is a document-level scripting environment, but it's not exposed to layers yet -- the JavaScript hooks to the compositing system don't exist yet, and the UI to tie it together with the timeline has not been designed. The way Flash implemented this is clearly pretty nasty, so I'd like to come up with something a bit cleaner, hopefully.

Re: the script editor command line -- it does print out eval results without wrapping them in sys.trace (so if you type "2+3" or "Object.keys(sys)", you get the expected printout -- unless of course I've broken that at some point without noticing). But clearly that UI leaves a lot to be desired. I'd like to do something about those floating panels anyway, so maybe I'll get to redesign the script editor at that point.

Congratulations, you are about to be offered a lot of money from a big company.

Do you take it? ... Or do you create a new software empire for the creative web development world to rival Adobe but built on open standards?

PS, If I was Apple I'd be buying this tomorrow, or I'd just amp up development of my own software, probably basing it on the new iAd Developer tools which were recently released.

Very cool! Nice job.

I noticed this: "Radi makes creating vector graphics easier with its unique autosmoothed shapes. When you apply smoothing to a corner point, all your control points lie precisely on the shape's outline. There are no separate "handles" or "tangent points" to be tweaked outside of the actual shape."

Just wanted to point out that, to me, that sounds like an anti-feature. Maybe it's a nice alternative tool for quick, smooth shapes, but I've watched many an illustrator tweak the hell out of those things to get exactly the right curves and sharp angels. I also remember reading a story about how Microsoft spent weeks observing video of expert Adobe suite users with various Pen-tools to get the feel of the handles juuust right for an easy transition to Expression suite products.

This is a cool side project and letting HN hammer on it is a great start, but you're going to need some artists to hammer on it before you've got something really special.

Just wanted to point out that, to me, that sounds like an anti-feature. Maybe it's a nice alternative tool for quick, smooth shapes, but I've watched many an illustrator tweak the hell out of those things to get exactly the right curves and sharp angles.

Right. I know that illustrators love their Bézier handles, but I'm not 100% convinced that everybody else loves them all that much. I used to do graphics for a living, and I never felt very comfortable with Béziers (although that was also because my style was pretty much opposite to sharp vector designs).

The Radi curve engine does support Béziers, but implementing the UI for managing the control points seemed like a complete drag (what a terrible pun).

So I figured that maybe I should try doing what Apple does so well: market the "anti-feature" as something new and unique. No handles -> less UI complexity -> ??? -> profit!

I was also inspired by 3D modelling applications, where a lot of work is done with subdivision surfaces which are controlled by automatic control points, essentially similar to the curves in Radi. I know there was an older generation of modelling apps with free-floating handles, and I get the impression that modellers are happy to be rid of those (but maybe I'm wrong about this one).

I guess we have here the Adobe Flash Studio for HTML5. Nice job!

This is the best Festivus present ever!

It's a Festivus miracle!

I hadn't seen this before, but on your main site, because you start talking about HTML5 so early (and the first headline says HTML5), I thought the site was a tutorial about the benefits of HTML5.

In my opinion I think you should reorder your site so that the first headline and blurb explain that Radi is a Mac Application for producting HTML5 compatible vector animations. The stuff about HTML5 can probably be below the fold.

Can it consume external data sources easily? At my company we have an XML RSS feed that I would like to transform into some sort of infographic display (dynamic bar charts, moving pie charts, tables, etc.)

Currently, we are solving this problem with a mish-mash of Ruby/Sinatra and jQuery/Raphaël but its not clean or easy. Would this be something that Radi could help us build and maintain?

That sounds like a very reasonable avenue to explore.

I've done a fair amount of work with dataflow UIs in the past, and it sounds like this could be an opportunity to leverage that work. To illustrate, here's a sample screenshot from my other product, Conduit Live (a video compositing app):

This kind of "connect-the-blocks" interface could work for describing the data loads and transformations in your use case. What do you think?

That looks like something that could work. Inspiration for that of course also from Yahoo Pipes which is made for services processing ; you can probably integrate a similar idea to create graphical representations of (processed) services. However, that would make it quite a different app and out-of-scope from what you are doing at the moment.

Very nice work! I've been wondering when someone would decide to go head-to-head with Adobe in the new world of HTML5 while they're still dragging their feet.

I'd especially love to see this ported to Linux. Also, is there a place where we can donate? I don't exactly have $200 to throw down on your other piece of software, and I don't own any iOS devices for your $1 app.

I wish all browsers become CSS3 and HTML5 compliant overnight. That would make the web a way better place.

Until then, all we can do to move that process along is to code spiffy sites that take advantage of CSS3 and HTML5 goodness, but degrade to a plain-but-usable version on inferior browsers, with a notification that they're missing out on an optimal experience by using that lousy browser.

I've been trying to asses the look of the sites I go to lately (mostly clean and simple ones). I like what you've done. Clean with just a touch of depth. I haven't consumed the content yet, but it looks tasty. I'm looking forward to trying the beta.

Just a quick note that I made an update to version 0.5.1:


Thank you all so much for the encouraging comments!

Someone's finalizing the huge potential in tooling for HTML5, good work.

Great, now make the app itself in HTML5. ;)

That's what i'm working on...

thats really amazing!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact