[erlang-questions] Two beautiful programs - or web programming made easy

[Edmond Begumisa]

Please have a look at this songbird screenshot...

http://cdn.freedownloadaday.com/wp-content/uploads/2007/03/Songbird.png

Songbird is a winamp-like media player. It's a XULRunner application so  
the UI you see there is just mark-up + css + js

Frédéric: you can thus get a graphic designer to do the cosmetics without  
him/her needing to learn to program.

Jerome: Notice the very application specific back/forward/refresh buttons  
there - in context it's much more useful than a generic browser  
back/forward/refresh. Also, the textbox where it says "Library", if you  
put your mouse there you get an application specific URI scheme that you  
can copy and paste somewhere else. The URI path takes you an item on tree  
on the left. Notice also the application-specific bookmarks.

This is currently my preferred way of delivering heavily interactive  
"internet applications" (even business applications) -- via a specialised  
runtime on the client end and Erlang on the server end. Joe's code gives  
me hope that I can finally start using the browser as a client for this  
instead without flash or plugins :)

- Edmond -

On Mon, 14 Feb 2011 08:52:07 +1100, Jerome Martin  
<jxm@REDACTED> wrote:

> Just on the back-button, not the history problem in general:
>
> 2011/2/13 Edmond Begumisa <ebegumisa@REDACTED>
>
>> [...]
>>
>> However, I've written XULRunner apps with no back buttons -- no need for
>> them with easy-to-navigate UIs. Most Adobe AIR apps I've seen have no
>> browser history. It's made me question: How badly do end-users really  
>> need
>> those things?
>
>
> I think users are _hooked_ to back-button, the same way most of us are
> hooked to undo. I find those two to be essentially the same, in terms of
> behavioral semantics. However, maybe the question here is whether or not  
> the
> history + back button functionalities being generic and implemented at  
> the
> browser level is a good thing, or if it is too restrictive. Clearly, "the
> web" has evolved, and still haven't swallowed the "web application" pill
> completely. Maybe a standard way to delegate 'undo/back' to the web
> application, could be useful, like a meta HTTP tag containing the URL to
> point at in case of the user using back/undo. But then I am not sure  
> anymore
> that HTTP/HTML is the proper foundation for this... An then suddenly I
> realize that this is too obvious an idea not to be thought by people  
> smarter
> than me, so I just looked up HTML5 on w3c site and voila:
> window.history.back() and window.history.forward() provide programmatic
> interfaces to browser back and forward functions in HTML5. See this
> page<http://www.w3.org/TR/html5/history.html#the-history-interface>,
> that one <http://html5demos.com/history> and maybe even this
> one<http://www.adequatelygood.com/2010/7/Saner-HTML5-History-Management>
> .
>
>
>> If they do, couldn't we give them better application-specific versions
>> inside our web-app UI?
>
>
> Asked myself that very question 2 minutes ago, and it seems HTML5 has the
> answer for us :-)
>
> So I would say that Joe's code could very much be well integrated in all
> HTML5-supporting browser, granted that the appropriate hooks are set on  
> the
> javascript side, and some standard logic hanging on those hooks on the
> erlang side (gen_html5app anyone ?).
>
> Thoughts ?


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/