PDA

View Full Version : Feature request and discussion: Flash/Ajax/... for UI



pfarrell
2006-07-09, 15:48
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/slimserver/slimsoftware.html

JJZolx
2006-07-09, 16:01
I believe this is a good thing to discuss a little
...
But the web is so last century.
Whoop - end of discussion.

stinkingpig
2006-07-09, 17:35
...
>
> 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
2006-07-09, 18:01
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
2006-07-09, 18:06
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
2006-07-09, 18:08
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
2006-07-09, 18:14
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
2006-07-09, 18:26
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
2006-07-09, 18:38
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
2006-07-09, 18:53
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/listmanager/license_recommender.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

CardinalFang
2006-07-10, 00:11
What is missing is a realistic discussion of the features
and functions that people think the SlimServer needs.


As one of the advocates of Flash as a possible solution, I ought to say why.

I was discussing the remote control that Sonus have and how by using Flash we could have something that runs on a low end device like a PSP as slickly - Nokia use it for some of their devices and they have a pretty good reputation.

Have we given ourselves the design restriction that a graphical UI remote and the server code have to have the same interface and code base? If we have, then I think that is a limitation as the server interface is usually for setup and maintenance, whereas the remote is for music selection and playback.

My concern is that in the "Flash is worthless eye candy" discussion I seemed to have kicked off, we're losing the point that the remote control has different priorities and perhaps the code and tool choice should be is more akin to the SB itself, not the server.

(EDIT, my real gripe is that the SB does not have a custim graphical remote control to match the new design. Whatever is done to improve the server interface will probably rely on technologies that aren't available on handhelds, and in any case they are no substiture for a dedicated, industrially designed remote)

Paul

mherger
2006-07-10, 00:15
Oh... this discussion is getting so emotional and personal... Most of what
is written here (in this thread, not this posting) is imho about personal
taste, or misunderstandings. But not facts. I'll have to add my _opinion_,
too.

>> But the web is so last century.

So what's today?

> 2 are used for corner-case hardware (Touch and Handheld),

But I think Handheld is pretty widely used. The fact that you can't see a
lot about it in the forums might be due to its simple design: (almost) no
javascript, frames, cookies or CSS guarantee for the best possible
compatibility with the sometimes very limited browsers on those movile
devices. We therefore don't have the hassles with Handheld kdf has to
fight with in Fishbone. It's simplicity by design (Handheld's creator
originally called it "Slimple" or something :-)).

> then most users use Default, ExBrowse, or Fishbone.

This is your assumption - and I'd really like to know better. I once
wanted to start a poll about it - excluding Default and Fishbone as I'm
assuming them to be top 2 anyway :-)

> Fishbone is the most ergonomic and pleasant to work with,

Now it's getting personal (about my taste, not about kdf's ;-)): I don't
like Fishbone. What's ergonomic about it? The default color set is
depressing (me). It's too cluttered (for me). And I don't like the
buttons. Yes, _I_ don't like it. I don't say it is ugly.

> Default is not very nice-looking

I love Default for it's simple and clean layout. Call me a purist. But I
don't need fancy, colorful skins. The colors are decent, not hurting my
eyes. In fact, I was searching for a nice web interface to manage my music
collection, when I first found out about slimdevices. Coming from Netjuke
I just loved that nicely looking Default skin - and stick with it since.
SlimDevices got an enthusiastic customer thanks to the Default skin.
That's my story :-)


> and desparately needs a jump toolbar instead of a breadcrumb trail,

I can't comment on this one as I don't understand... What's a "jump
toolbar"?

> 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.

What's wrong about the current CLI. I think it's (almost) all there. I
wouldn't call my SlimRemote the sexiest app on earth, but it does imho
demonstrate a lot that can be done with the current CLI, even on handheld
devices.

And then I wanted to comment on the Flash discussion... but that was in
the old thread. Have missed that one. I'd just add that Flash doesn't have
to be as bad as its calling. I'm sure even Michael (Wagner) has used some
Flash he didn't dislike. And he didn't notice, because it was _good_
design and good Flash usage. Good design and usage of a tool is when you
don't notice it.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

erland
2006-07-10, 01:34
When discussing flash interface, please bear in mind that all plugin developers might not be interested in investing $399 in a flash license. I think it is a good idea to keep making language choices for slimserver in such way that its possible to contribute without purchasing expensive development tools.

I think we have two main use cases where the "web interface" needs to work:

1. Control of slimserver using a handheld device
- Has to work on small screens
- Has to work on as many different handheld devices as possible

2. Control of slimserver from your desktop PC
- Has to work on all main operating system (Windows, Linux, MaxOS)
- Preferable if it takes advantage of the screen space
- Preferable if it integrates with the OS with tray icons, drag&drop, notifications when a new track starts playing and much more.

In the second case I think a fat client would really be the best choice for the user, look at Moose for an example. The problem with this is that fat client is really not that easy to combine with operating system independence. So due to this I think a web interface probably is the right way to go also for the second case. Fat clients can still be developed by external developers, but I think it might be a bad idea to include these in the standard slimserver.

A third case that probably will be requested more in the future is integration with HTPC software like MCE, MediaPortal, Myth.

CardinalFang
2006-07-10, 05:03
1. Control of slimserver using a handheld device
- Has to work on small screens
- Has to work on as many different handheld devices as possible


But why does it have to work on so many devices? Why not just one, a dedicated device? Using PDAs and PSPs (even though I have one and would use an interface) is really a halfway house when what the competition (Sonus) have is a custom device and it is so well received. I honestly think the remote needs to be a dedicated, engineered product like the SB3, otherwise it will always feel like an afterthought to the average user.

mherger
2006-07-10, 05:10
> But why does it have to work on so many devices? Why not just one, a
> dedicated device?

Because I don't want to spend another few hundred bucks for a remote
control.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

CardinalFang
2006-07-10, 05:52
> But why does it have to work on so many devices? Why not just one, a
> dedicated device?

Because I don't want to spend another few hundred bucks for a remote control.


Fair enough, but I don't want to have to go out and buy a 770 or a PDA just to be able to control my music half as well as a Sonus unit. 770's and PDAs cost a few hundred dollars too.

It's a laudable idea and quite cool that the server interface works on many different devices so that if you have one handy, you can use it, but I don't have one and would prefer a dedicated solution with instantaneous start-up and no launching web browsers just to get a different tune selected.

I want the right physical buttons in the right place for music search and playback control, scroll wheels and fast screen updates, not the best compromise as part of a one-size-fits-all solution. If Slim made one, I'd buy it in preference anyday, but it seems to me I'm not going to get it.

Paul

bklaas
2006-07-10, 07:43
...[color=blue]
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've given a lot of thought to this, because one of my discoveries in developing the 770 skin is that it works fantastically from a POPC (plain-old-PC) using Firefox or Opera. The only problem with using the Nokia770 skin on a pc is that I did a lot of CSS to format the skin for the 770's 800x480 touchscreen. With a little elbow grease, I think I could create a new skin that maintains the simple look-and-feel of what I did (and to some extent, stole from "Touch"), formats to a larger screen better, and maybe adds a bell here, a whistle there.

The main thing that is keeping me from doing this is having to deal with IE and all of the baggage supporting that hunk of junk brings. With Nokia770 skin, I can avoid IE by explicitly saying that the skin is not for IE. If I wrote a general skin, that luxury disappears. Suddenly the job isn't as fun any more...we'll see. (also, having two little daughters doesn't speed development much either ;) ).

cheers,
#!/ben

oreillymj
2006-07-10, 07:45
I can't comment on this one as I don't understand... What's a "jump toolbar"?

A jump toolbar is a dropdown list, where each item in the list re-directs you to a URL.
Dreamweaver calls them jump-menu's. I'm assuming that's what's being referred to.

Personally I think Flash would be a good fit for a PSP or handheld Skin, but the UI would ten essentially become "closed source" as few people would have the resources to make any changes.

I think Ajax could be used to produce a very user friendly skin and would be nice if used to enhance Default. That layout is probably the cleanist in my opinion.

Sonos have a very nice remote and probably have applied for patents on their integration of a Scrollwheel into a remote for a Networked audio player which stops Slikm from implementing soething similar.

I did post a functioning HTML/Javascript onscreen scrollwheel to a thread about a PSP skin, but no-one seemed interested. It could be integrated into the Handheld/770 skins.

mherger
2006-07-10, 07:57
> A jump toolbar is a dropdown list, where each item in the list
> re-directs you to a URL.

....so... basically what is now used in the settings pages of the trunk?

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

bklaas
2006-07-10, 07:59
Fair enough, but I don't want to have to go out and buy a 770 or a PDA just to be able to control my music half as well as a Sonus unit. 770's and PDAs cost a few hundred dollars too.

It's a laudable idea and quite cool that the server interface works on many different devices so that if you have one handy, you can use it, but I don't have one and would prefer a dedicated solution with instantaneous start-up and no launching web browsers just to get a different tune selected.

I want the right physical buttons in the right place for music search and playback control, scroll wheels and fast screen updates, not the best compromise as part of a one-size-fits-all solution. If Slim made one, I'd buy it in preference anyday, but it seems to me I'm not going to get it.

Paul

Even though there's been a fair bit of vitriol sprayed back and forth on this whole "flash interface" subthread, I don't think your ideas are invalid. I'm not a flash fan for many of the reasons already brought up (needs browser plugin, proprietary, costs an absurd amount of money for a developer to get started with it, is not truly cross-platform), but I'm not one to shun great UI work just because of the underlying technology.

FWIW, I don't think there's anything stopping someone from developing a flash interface using the slimserver CLI as an API. There is also no reason that said interface would have to follow the same convention as a standard skin, either.



Have we given ourselves the design restriction that a graphical UI remote and the server code have to have the same interface and code base?


I don't think I quite understand your question, but I believe the answer is NO. I believe the slimserver CLI would allow you to build a graphical UI in whatever way you'd see fit.

One last thing: Why don't you sell your Squeezebox and buy a Sonos? Is there something that's keeping you aligned with Slim for your streaming audio needs? I don't mean to put you off with that question, I'm just trying to figure out why you wouldn't already be a Sonos owner if the remote is so appealing to you... If it's cost that's holding you back from Sonos, you should drop the "slim needs to build a graphical remote" thing, because there's no way a squeezebox plus slimgraphicalremote would be appreciably cheaper than the Sonos solution.

#!/ben

mikerob
2006-07-10, 09:35
because there's no way a squeezebox plus slimgraphicalremote would be appreciably cheaper than the Sonos solution.

#!/ben

These are UK prices but a minimal Sonos setup (2 x ZP80 Zone Players and a Controller - the remote) comes in at 779 while a Squeezebox is 215 so the Squeezebox is 564 or about US$1000 cheaper.

ajmitchell
2006-07-10, 09:39
Mike that doesn't seem a fair Sonos comparison given that the small package you quote is *two* Zp80s giving two distinct zones out-of-the-box (albeit one wired). Thus I would say with the new Zp80s the price differential is much narrower than previously

2xZp80 + graphic controller = 779

2 Sb3s (215) = 430

Differential = 349 (just about the cost of the fancy remote when bought seperately.

For me, its a very tough choice, but I am a slim fan and prefer (slight differences in) quality over (modest differences in) image/presentation. Also Sonos will not update itunes as it plays, once it does.....who knows I may change.

ps.

Perhaps there could be a new sub-forum specificallu for feature requests???

)p(
2006-07-10, 10:33
One last thing: Why don't you sell your Squeezebox and buy a Sonos? Is there something that's keeping you aligned with Slim for your streaming audio needs? I don't mean to put you off with that question, I'm just trying to figure out why you wouldn't already be a Sonos owner if the remote is so appealing to you... If it's cost that's holding you back from Sonos, you should drop the "slim needs to build a graphical remote" thing, because there's no way a squeezebox plus slimgraphicalremote would be appreciably cheaper than the Sonos solution.

#!/ben

I am considering just doing that. I agree with Paul about the need for better quality and more professional looking user interfaces both for a gui remote and a pc application. Sonos was not an option before the zp80. But now it is! I will miss the display with the zp80 and some of the really cool plugins though. And the sb3 just looks better anyway. So I'll proabably wait just a little longer to see if slim will come up with something as good.

peter

CardinalFang
2006-07-10, 11:41
One last thing: Why don't you sell your Squeezebox and buy a Sonos? Is there something that's keeping you aligned with Slim for your streaming audio needs?

Yes, audio quality. The SB sounds better, it was my #1 reason for buying it. The rest of my gear costs a lot more and I bought a dedicated DAC for the SB. I just want a better way of choosing and playing music and I'm willing to pay for a good remote. I don't want a Sonus because it was sonically inferior, as is the Roku. If the Sonus improves through a DAC, then I'll probably switch if Slim don't improve the remote. That's not a threat, I just want the best solution.

I also don't believe a remote has to cost as much as the Sonus unit, in fact if Slim wrote something for the PSP, that would keep me happy - it has a good layout of buttons and a lovely screen - and it costs under 200. (I have one already as it happens) 200 PSP + 50 remote control application, that works for me. I've used the handheld skin, but it is just too clunky. I want album art and animated menus and nice transparency effects. Yes, I'm asking for the moon on a stick, but it's not that hard if done as a native PSP app. I don't want free if it isn't as good.

EDIT - when we're looking at prices for remote, don't forget that the sums we're talking about are less than many audiphiles spend on cables. A really nice remote woud go down really well.

Paul

mikerob
2006-07-10, 11:59
Mike that doesn't seem a fair Sonos comparison given that the small package you quote is *two* Zp80s giving two distinct zones out-of-the-box (albeit one wired). Thus I would say with the new Zp80s the price differential is much narrower than previously

2xZp80 + graphic controller = 779

2 Sb3s (215) = 430

Differential = 349 (just about the cost of the fancy remote when bought seperately.

For me, its a very tough choice, but I am a slim fan and prefer (slight differences in) quality over (modest differences in) image/presentation. Also Sonos will not update itunes as it plays, once it does.....who knows I may change.

ps.

Perhaps there could be a new sub-forum specificallu for feature requests???

Fair point... however I think in the Sonos system with just one Zone Player, you must have this connected to the music source and wireless router with a wired connection, which isn't the case with the Squeezebox.

In my particular setup with a computer and wireless router in one room and hifi system in another room, I'd need to have a Zone Player in the room with the computer where I don't listen to music and then have another Zone Player in the other room to listen to my hifi.

CardinalFang
2006-07-10, 12:00
I don't think I quite understand your question, but I believe the answer is NO. I believe the slimserver CLI would allow you to build a graphical UI in whatever way you'd see fit.

My point was that you can only select one skin at a time, not per device or computer. So the same skin appears on both PC and handheld, but in my case they would be used for differing task, one ofor maintenance and setup, the other for browsing and selecting music.

Do skins need to be selectable for "device class"? i.e. one skin is setup for server maintenance devices, another one for remote controls? You would have to associate a skin type with a different port number I suppose. 9000 for servers, 9001 for remotes etc.

CardinalFang
2006-07-10, 12:07
In my particular setup with a computer and wireless router in one room and hifi system in another room, I'd need to have a Zone Player in the room with the computer where I don't listen to music and then have another Zone Player in the other room to listen to my hifi.

It's another reason I didn't go Sonus, you essentially waste a zoneplayer as an expensive wireless router. Slim has the better server/client approach and now has good industrial design, but the remote now looks lacking and I personally think that a web page on a PDA doesn't really cut it as part of an audio set-up. It's a good kludge, but still a kludge.

I see it like the GPS car systems, originally they were PDAs with apps and plug-in cards, clever, but not ideal. Now they are all dedicated devices that start up quicker and have optimally designed UIs and physical control layouts - and they are cheaper.

Paul

bklaas
2006-07-10, 12:10
My point was that you can only select one skin at a time, not per device or computer. So the same skin appears on both PC and handheld, but in my case they would be used for differing task, one ofor maintenance and setup, the other for browsing and selecting music.


That's not true. http://localhost:9000/Fishbone/ will let you use Fishbone, even if Handheld is configured as your default skin.

#!/ben

CardinalFang
2006-07-10, 12:20
That's not true. http://localhost:9000/Fishbone/ will let you use Fishbone, even if Handheld is configured as your default skin.

#!/ben

I stand corrected.

Not exactly elegant though, is it? I can imagine having to explain that one to my wife or kids when she wants to use a remote control when I have the right skin default for server maintenance. Sure I can set it up that way with bookmarks, but imagine having to sell that to someone in a store. My solution was no better, I'll grant you that.

It might be nicer if it could auto-detect on the index page according to screen layout or size, although I suspect people will throw their arms up in horror at that too. It's all just a bit too geeky for the average user IMHO, and it needn't be.

Paul

oreillymj
2006-07-10, 14:57
How about setting http://<slimserverip>:9000/handheld as the homepage on your pda?
Or just add to the browsers bookmarks.

oreillymj
2006-07-10, 15:05
BTW Flashy skins are all well and good, but something that would make Slimserver more useful would be automatic detection of new music and additional to the library.

I'm wondering if this is something that has been difficult to implement due to Slim supporting multiple OS's.
There are Windows API's for "watching" directories for changes. I'm sure that same also exists for Mac & Linux, but perhaps the implementation is different enough to make programming this feature 3 distinct jobs.

If Slimserver detected new music, optionally Replaygained it, and added it to the library automatically it would cut down the learning curve for new users considerably.

Slimserver could then install something like CDex for beginners and set the default rip path to match the users selected music directory.

Then adding to Slimserver becomes a simple job of imserting a Cd, fire up CdEx and click rip.

Simon Still
2006-07-10, 15:37
On 7/10/06, oreillymj <
oreillymj.2ar25z1152568801 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> How about setting http://<slimserverip>:9000/handheld as the homepage on
> your pda?
> Or just add to the browsers bookmarks.
>
> Indeed, my Nokia 770 has the icon bookmark on the desktop as a Squeezebox
image that launches the handheld skin (i'm running 6.3). That skin does
have some issues -- particularly with changing the player it's controlling.


I'm not a big fan of skins. Obviously Slim needs a few aimed at different
devices but frankly the unmaintained 'not fishbone/default/exbrowse' should
be plug ins rather than in the default distribution.

Michaelwagner
2006-07-10, 21:47
I'm sure even Michael (Wagner) has used some
Flash he didn't dislike. And he didn't notice, because it was _good_ design and good Flash usage. Good design and usage of a tool is when you don't notice it.
That's probably a fair comment.

I don't always check how something is implemented. If it's clean, appropriate, not confusing, just works and not full of whiz-bangs, I pass over it happily and go on with the work at hand.

Michaelwagner
2006-07-10, 21:50
(also, having two little daughters doesn't speed development much either ;) ).
Summer's coming. Give them a summer job coding :-)

Michaelwagner
2006-07-10, 22:10
Hmm...a lot of interesting thoughts here.

I think we are overlooking a lot of important Slim flexibility.

The web interface attempts to be all things to all people on all platforms (combinations of O/S and browser).

As such, I think it ends up being jack of all trades, master of none.

A tremendous amount of work has gone into the CLI since Slimserver 5 days, and it now seems to be quite a viable interface. There are bulk data extraction options, event driven options with the listeners, there is current status stuff that is fast.

That gives people who want a different interface the ability to write their own. Or use someone elses.

Moose is one. For all that people like or don't like .net, the version I downloaded some time ago was quite serviceable and I gather it's improved since.

I considered writing one in my favorite language, Visual Foxpro. It won't port to a mac, but I don't own one. It won't run on Linux, but I don't have any of those either. Nor a Unix. I also don't have a Cray. The point is, sometimes you can do a better job, especially when trying to do graphics rich, highly interactive things, when you do get a bit more implementation specific. There's nothing wrong with that, and nothing that offends the gods of cross-platform. No one says the whole thing, and everything that anyone would ever chose to use with it, has to run on every conceivable platform from Windows to a slug to my toaster.

For instance, everyone has their own music ripper. These pretty much line up by platform. No one seems to feel that you have to run a perl based CD ripper in order to be following the spirit of Slim. Similarly, there'd be nothing wrong with a windows only UI implementation, running as a CLI client and a totally different one for the mac, for the palm, for the penguin, etc.

Trying to make them all run one set of common code might well, unfortunately, end up with a least common denominator UI. And that might be pretty sad.