Feature request and discussion: Flash/Ajax/... for UI

[pfarrell]

In the thread titled: Re: Stereophile's visit to Sonos
there is a lot of discussion about alternative UI for
the SlimServer, Flash, Ajax, and other technologies
that are a lot more modern and sexy than boring old
HTML.

I believe this is a good thing to discuss a little,
altho selection of one tool or another really
belongs on the developers list.
This is the users list, so descriptions of what
cool features are desired is fair game.

kdf wrote:
> has anyone looked into the Google toolkit?
> http://code.google.com/webtoolkit/

I have, and as complex APIs go, it isn't too bad. But
it is a ton more complex than writing HTML with CSS.
More worrysome to me is that it would bind a great
open source product into a vendor's toolkit. I can
see pluses in using any big vendor's toolkit, but
one has to acknowledge that any vendor's needs are
not always in line with the open source community.
Not to pick on Google, you can say the same thing
about Microsoft, Adobe, Yahoo, Oracle, etc.

> I found it not too hard to add some ajax to the Fishbone skin, using
> prototype.js as the base. However, there is a limit to what that can
> do without adding much more complicated framework. I don't think
> that drag & drop will work using that. And, of course, drag and drop
> from outside the browser is even more of a mystery.

I think this is key. What people want is drag and drop everywhere.
They want to drag an album just ripped with something like CDex or EAC
and drop it into the Slimserver, and have the files move
to the right place, the database updated, etc.

This might be a bit of an exaggeration, but I haven't see a well worded
request that is less grandiose. And I sure don't have any idea
how one would really implement such a thing. Or how many folks
really would want it, and would want it over any of the
other "top 50" requests.



> I'm a strong believer is using the web for the ui. It allows a
> ready-made platform instead of using up resources just to maintain an
> application framework for MANY different OS's. Don't ever
> underestimate the difficulties in maintaining a common interface
> across even multiple windows versions, let alone OSX and the many
> flavours of linux. Slimserver provides options for API's so that
> third parties can create their own preferred UI on their preferred
> OS. The popularity of JRiver is a good example. Why not campaign
> those developers to create hooks for the CLI, and the importers.

But the web is so last century. It is understood and works. No reason
to keep using it.

The Flash discussion seems to have split into two views of it, neither
of which I think are important to this discussion. There is Flash the
video/blinking object eyecandy, and there is Flash the universal runtime
tool that does the same kinds of things that Ajax (or the Windows API)
do. With Flash, you can develop some very cool user interfaces that
work on lots of platforms, at least all modern Windows, Mac OS-X and
recent Linux/*BSD systems. I am going to give credit to the folks
that suggest usign Flash that they do not mean the heavy, bandwidth
eating eye candy that deserves to be cursed, but rather the
"Flash as platform" model that Macromedia has been pushing for at least
a year. As a platform, Flash can do good things.

The downside IMHO to Flash the platform, is the per-seat price
for developers. It is far too high to work for contributors in
something like SlimServer.

But the price is just an implementation barrier.

What is missing is a realistic discussion of the features
and functions that people think the SlimServer needs.


--
Pat
http://www.pfarrell.com/music/slimse...msoftware.html

[JJZolx]

I believe this is a good thing to discuss a little
...
But the web is so last century.

Whoop - end of discussion.

[stinkingpig]

...
>
> This might be a bit of an exaggeration, but I haven't see a well worded
> request that is less grandiose. And I sure don't have any idea
> how one would really implement such a thing. Or how many folks
> really would want it, and would want it over any of the
> other "top 50" requests.



One thing to keep in mind is that a big paradigm shift like "enable drag and
drop every where" will invalidate half of the top fifty requests... either
they'll be solved by it or they'll be moot with it. If this statement isn't
true for a particular paradigm shift, then that's a good indication of a bad
idea

> I'm a strong believer is using the web for the ui. It allows a
> > ready-made platform instead of using up resources just to maintain an
> > application framework for MANY different OS's. Don't ever
> > underestimate the difficulties in maintaining a common interface
> > across even multiple windows versions, let alone OSX and the many
> > flavours of linux. Slimserver provides options for API's so that
> > third parties can create their own preferred UI on their preferred
> > OS. The popularity of JRiver is a good example. Why not campaign
> > those developers to create hooks for the CLI, and the importers.
>
> But the web is so last century. It is understood and works. No reason
> to keep using it.


LOL


>
> What is missing is a realistic discussion of the features
> and functions that people think the SlimServer needs.
>
>
By "realistic" I assume you mean "keeping an eye on the roadmap", which
means that it's got to stay cross-platform. The only sensible way to keep it
cross-platform is to use a web interface, or at least a web-delivered
interface. Flash and AJAX are two methods to reach the same goal, which is a
more responsive and sexier web interface. This is A Good Thing(TM) in my
book, with one caveat. There are 12 skins in the SlimServer 6.3 download,
they all have problems, and they all have different problems. 7 of the skins
are basically dead, or at least generate no user comments, 2 are used for
corner-case hardware (Touch and Handheld), then most users use Default,
ExBrowse, or Fishbone.

Fishbone is the most ergonomic and pleasant to work with, but has annoying
cookie bugs. Fire up some loud punk on the Squeezebox in the room where your
kids are sleeping once or twice because the skin got confused, and you quit
using the web UI real fast.

ExBrowse is also pretty nice to work with, but has annoying state-loss bugs.
Shift-reload, wait 30 seconds, and re-navigate to where you were gets old
after a while.

Default is not very nice-looking and desparately needs a jump toolbar
instead of a breadcrumb trail, but it's damn stable. No crashes, no
mistakes, it just does what it's supposed to do... too bad it doesn't look
as good as Fisbone

My dream? A single new skin that looks like Fishbone, is stable like
Default, and is powered by Ben's sexed-up Nokia770 AJAXness. I'd also like a
robust telnet CLI that makes it easy for anyone to write a native interface
in any language they like for any platform they like.

Oddly enough, the second one has already happened, which is a good sign that
the folks driving the bus really do have an eye on the road.
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

[kdf]

On 9-Jul-06, at 5:35 PM, Jack Coates wrote:
>
> Fishbone is the most ergonomic and pleasant to work with, but has
> annoying cookie bugs. Fire up some loud punk on the Squeezebox in the
> room where your kids are sleeping once or twice because the skin got
> confused, and you quit using the web UI real fast.

6.5 uses cookies for all skins when tracking the current player.
hopefully this means I'm no longer alone at trying to support it and it
results in a more stable solution. i've also spent a lot more time
with 6.5 trying to make sure accidents don't happen. if you have a
reproducable case, let me know.
>
> My dream? A single new skin that looks like Fishbone, is stable like
> Default, and is powered by Ben's sexed-up Nokia770 AJAXness.
Fishbone shares some of the ajax code for the now playing status in
6.5. That is probably as far as I'll go, thanks mostly to IE and its
ability to make me want to kill every living thing I see when trying to
make anything work outside of plain old html. Even v7 beta isn't
showing signs of anything that gives me hope.
-k

[Jacob Potter]

On 7/9/06, Jack Coates <jack (AT) monkeynoodle (DOT) org> wrote:
> Oddly enough, the second one has already happened, which is a good sign that
> the folks driving the bus really do have an eye on the road.

My hope is that SlimServer 7.0 will use the Catalyst framework for the
web interface. Easily-customizable controller code should make more
elaborate skin development much easier. (I'd prefer a better template
language too - Kid has spoiled me - but I'll take what I can get )

BTW, what are the state-loss bugs you've seen in EB? I'm poking at
some playlist-updating issues now, but anything else is news to me.

- Jacob

[stinkingpig]

On 7/9/06, kdf <slim-mail (AT) deane-freeman (DOT) com> wrote:
>
>
> On 9-Jul-06, at 5:35 PM, Jack Coates wrote:
> >
> > Fishbone is the most ergonomic and pleasant to work with, but has
> > annoying cookie bugs. Fire up some loud punk on the Squeezebox in the
> > room where your kids are sleeping once or twice because the skin got
> > confused, and you quit using the web UI real fast.
>
> 6.5 uses cookies for all skins when tracking the current player.
> hopefully this means I'm no longer alone at trying to support it and it
> results in a more stable solution. i've also spent a lot more time
> with 6.5 trying to make sure accidents don't happen. if you have a
> reproducable case, let me know.



Totally reproducible in 6.3, do you want to see those or only 6.5?

>
> > My dream? A single new skin that looks like Fishbone, is stable like
> > Default, and is powered by Ben's sexed-up Nokia770 AJAXness.
> Fishbone shares some of the ajax code for the now playing status in
> 6.5. That is probably as far as I'll go, thanks mostly to IE and its
> ability to make me want to kill every living thing I see when trying to
> make anything work outside of plain old html. Even v7 beta isn't
> showing signs of anything that gives me hope.
> -k
>
>
I hear you, I've done a little bit of Javascript development too. Wrote it
with Firefox and Venkman, it completely failed in Opera and MSIE. I was able
to get a single version to work for Opera and all Mozilla branches, but
nothing could be done for MSIE, I had to do a browser detection and branch
into alternate code in order to maintain state and read variables. GAH!!!
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

[stinkingpig]

On 7/9/06, Jacob Potter <jacobdp (AT) gmail (DOT) com> wrote:
>
> On 7/9/06, Jack Coates <jack (AT) monkeynoodle (DOT) org> wrote:
> > Oddly enough, the second one has already happened, which is a good sign
> that
> > the folks driving the bus really do have an eye on the road.
>
> My hope is that SlimServer 7.0 will use the Catalyst framework for the
> web interface. Easily-customizable controller code should make more
> elaborate skin development much easier. (I'd prefer a better template
> language too - Kid has spoiled me - but I'll take what I can get )
>
> BTW, what are the state-loss bugs you've seen in EB? I'm poking at
> some playlist-updating issues now, but anything else is news to me.
>
> - Jacob


I haven't tried 6.3, I'll switch to it and let you know if there's still a
problem. No artwork at the album leve is a problem, but that's by design
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional

[Jacob Potter]

On 7/9/06, Jack Coates <jack (AT) monkeynoodle (DOT) org> wrote:
>
> I hear you, I've done a little bit of Javascript development too. Wrote it
> with Firefox and Venkman, it completely failed in Opera and MSIE. I was able
> to get a single version to work for Opera and all Mozilla branches, but
> nothing could be done for MSIE, I had to do a browser detection and branch
> into alternate code in order to maintain state and read variables. GAH!!!

What were you doing? Minus the whole XMLHttpRequest thing, and a few
syntax quirks in Safari (it doesn't accept trailing commas in object
or array literals), I haven't had any cross-browser issues with
Javascript.

CSS, on the other hand... well, let's not even go there.

- Jacob

[kdf]

On 9-Jul-06, at 6:08 PM, Jack Coates wrote:

>> .
>
> Totally reproducible in 6.3, do you want to see those or only 6.5?
>
If you try 6.5 at some point, let me know if you can reproduce it in
that...would be my preference.
If that isn't feasable, please list the steps to reproduce with 6.3. I
may have already fixed it with 6.5, but I might be able to backport.

-k

[stinkingpig]

On 7/9/06, Jacob Potter <jacobdp (AT) gmail (DOT) com> wrote:
>
> On 7/9/06, Jack Coates <jack (AT) monkeynoodle (DOT) org> wrote:
> >
> > I hear you, I've done a little bit of Javascript development too. Wrote
> it
> > with Firefox and Venkman, it completely failed in Opera and MSIE. I was
> able
> > to get a single version to work for Opera and all Mozilla branches, but
> > nothing could be done for MSIE, I had to do a browser detection and
> branch
> > into alternate code in order to maintain state and read variables.
> GAH!!!
>
> What were you doing? Minus the whole XMLHttpRequest thing, and a few
> syntax quirks in Safari (it doesn't accept trailing commas in object
> or array literals), I haven't had any cross-browser issues with
> Javascript.
>
> CSS, on the other hand... well, let's not even go there.
>
> Nothing too fancy, which is why I was so annoyed at the difficulty
level... it took a couple of hours to figure out the logic, a day to make it
work in Mozilla, and nearly a week to make it work in MSIE and Opera
(equally bad browsers, IMHO, at least as far as JavaScript standard
compliance goes).

http://www.lyris.com/products/listma...commender.html

Each subsequent question's drop-down choices are re-written by the choices
you make in previous questions.
--
"I spent all me tin with the ladies drinking gin,
So across the Western ocean I must wander" -- traditional