Well whatever said and done I feel the SBS + IPeng interface is
preferable to iTunes remote. It lets you select play next or add to
playlist as options. You can create a playlist.
iTunes remote is quite primitive in comparison IMHO. No way to create a
playlist.
--
sxr71
Interesting thread, if a little esoteric on the 'options vs defaults'
:D
My single objection with the Duet is that it is far too easy to delete
the current playlist.
On no other system or application I own does pressing play delete the
playlist. This is not standard behaviour and is contrary
On no other system or application I own does pressing play delete the
playlist. This is not standard behaviour and is contrary to the user
expectation.
On the contrary, I think it's quite common. eg. on an iPod, if you press play
when browsing to anything, it immediately starts to play that
Philip Meyer;576263 Wrote:
On no other system or application I own does pressing play delete the
playlist. This is not standard behaviour and is contrary to the user
expectation.
On the contrary, I think it's quite common. eg. on an iPod, if you
press play when browsing to anything, it
chroma;472758 Wrote:
Agree with this. I also am in support of a fast double-click to play
now on the touch interfaces. Its annoying each time i want to play
something to have to hold and wait. it is useful sometimes. but not in
the normal case.
+1
It simply takes too many clicks to get
It simply takes too many clicks to get to an album and play it on the
Touch. Making a double click on the album title equal the play button
on the remote would be a welcome addition.
I agree that it would be nice to quickly play an album. However, I don't think
a double-touch would work too
Philip Meyer;568126 Wrote:
It would also slow down normal navigation slightly - perhaps feel a bit
sluggish. i.e. on the first touch, it would have to wait a little bit
before responding, in case there's another touch to follow. And if a
user's second touch was slightly too late, it
Take TTP as an example.
TTP?
And these were just two simple options.
Options/functionality - it's all the same - conditions in the code. It just
adds up to a number of function points. And performance need not be impacted,
if it's done right.
The examples you gave will have many
Apple might be another great example of this concept. iTunes sucks badly for
anyone who wants to have control over his music collection. But still it's
probably the single most used audio player. (thanks to iPod too...)
And yet even iTunes (agree, it does suck!) and iPods have many options for
My iPod touch has 4 (!) options for the whole music player
functionality.
--
pippin
---
see iPeng, the Squeezebox iPhone remote, at penguinlovesmusic.com
pippin's Profile:
mherger;494470 Wrote:
37signals (authors of Getting Real) have built their company around a
certain degree of confidence/arrogance - it's their way or the
highway.
They are doing alright for themselves.
Apple might be another great example of this concept. iTunes sucks
badly for
There are many reasons to criticise iTunes; it can be slow, bloated, it
arguably tries to do a lot more than it should, but as a music manager
what exactly is wrong with it?
Hey, it's not about which software sucks and which doesn't, nor is this about
iTunes. I only took it as an exampel for
Luke Redpath;494567 Wrote:
Can't say I've ever had a problem with iTunes; not sure exactly how you
define control over his music. My music stays organized and is easily
accessible which is all I (and most people) are looking for.
Yep. But as soon as you sync it with a source outside your
Philip Meyer;494485 Wrote:
And yet even iTunes (agree, it does suck!) and iPods have many options
for a simple audio player.
Besides the obvious missing support for some music file formats, what's
so bad with it ?
What kind of functionality do you have in the Squeezebox interface that
you
mherger;494582 Wrote:
And many others eg. don't like the way it organizes your music in
folders. Yes, you can turn it off, but I'd like to have it automatic,
but different... See what I want to say?
Well, SBS also has restrictions how you should organize your music, for
example it doesn't
erland;494591 Wrote:
I personally wish SBS and Squeezebox would be able to continue to the
next step and focus on enhancing the music browsing and listening
experience. For example things like smart playlists, support for ratings
and other statistics, support for classical music
Luke Redpath;494431 Wrote:
There certainly is an element of arrogance to it (or you could say
confidence), I won't deny it. You say that as if it is a bad thing, but
that would depend on your point of view.
37signals (authors of Getting Real) have built their company around a
certain
What I feel needs some attention in the future is the whole concept of
contextual meta-navigation... like MUSE for example. There's fantastic
latent capability for navigating ones collection via all sorts of
meta-linkages. Of course, they'll depend on tags... (oh bugger).
I'll get my coat...
--
Besides the obvious missing support for some music file formats, what's
so bad with iTunes?
Oh, there's so many things...
- Exploding compilation track artists into the list of artists.
- No support for multiple tags (aritsts, genres).
- CD autoplay automatically brings up album ripper (overrides
Luke Redpath;493876 Wrote:
Not really a philosophy I subscribe to.
http://gettingreal.37signals.com/ch06_Avoid_Preferences.php
Perhaps its better to say too many preferences are evil.
Of course, you're welcom to disagree and if so Squeemote might not be
for you.
The referenced URL
With all respect, for any non-trivial software the assertion that there
is a single best use path and that a business
analyst/architect/programmer has the expertise to find it is
terrifically arrogant. It also has more than a whiff of justification
of programmer laziness...
Funny, I was thinking
stephenkca;494245 Wrote:
it's easier to hard code a value than look up a preference, and it makes
support and debugging easier.
Which in turn means you get software with fewer bugs and better
performance.
--
pippin
---
see iPeng, the Squeezebox iPhone remote, at penguinlovesmusic.com
Which in turn means you get software with fewer bugs and better
performance.
Only if not designed and tested properly. Honestly, there's plenty of examples
of software with many many options that work well.
Conversely, you deliver something that doesn't meet anyones specific needs.
Philip Meyer;494354 Wrote:
Which in turn means you get software with fewer bugs and better
performance.
Only if not designed and tested properly.
No. More complexity means more bugs and less performance or more work
which means less features or higher price.
There is no free lunch.
You can
No. More complexity means more bugs and less performance or more work
which means less features or higher price.
No it doesn't mean that for certain. Bolting on stuff later could mean more
work and more bugs (depending on the quality of the initial
design/implementation/code review/test), but
Philip Meyer;494391 Wrote:
No. More complexity means more bugs and less performance or more work
which means less features or higher price.
No it doesn't mean that for certain. Bolting on stuff later could mean
more work and more bugs (depending on the quality of the initial
pippin;494401 Wrote:
Take TTP as an example.
Hard coding the behavior makes for a straightforward approach.
...
If you do all this using options, you also have to have an options
menu. You now have:
...more
satisfied customers. I don't care how hard Ben his colleagues have to
work
peterw;494404 Wrote:
...more
satisfied customers.
...
I don't care is a few more if/else constructs bloat the code.
Not necessarily. Bloated code means less performance and give a defined
set of resources having to work harder means dropping something else.
SBS is already horribly slow
Just another wonderful example: I just spend an hour moving back from
7.5.0 embedded to main because of an option having a side effect:
http://forums.slimdevices.com/showthread.php?t=72474
NOT having an option and hard coding:
embedded - SQLite
main - MySQL
would have avoided that.
--
pippin
stephenkca;494245 Wrote:
With all respect, for any non-trivial software the assertion that there
is a single best use path and that a business
analyst/architect/programmer has the expertise to find it is
terrifically arrogant.
There certainly is an element of arrogance to it (or you could
pippin;494401 Wrote:
Sorry, but repeating this doesn't make it true.
Take TTP as an example.
Hard coding the behavior makes for a straightforward approach. You have
an action and this action will result in some message being sent to some
object. Simple use case, simple test case.
Add a
37signals (authors of Getting Real) have built their company around a
certain degree of confidence/arrogance - it's their way or the highway.
They are doing alright for themselves.
Apple might be another great example of this concept. iTunes sucks badly for
anyone who wants to have control
Aside from people being different, so are the different physical
interfaces.
Touch interfaces (SBTouch, iPeng and Squeemote) need a different
approach than the button driven interfaces but at the same time, users
may jump between interfaces and want some consistency between them.
The
Phil Leigh;493645 Wrote:
The one thing EVERY UI developer forgets is that people are ...
different.
Maybe because that information alone is of little help with designing a
UI?
The ONE thing that definitely does NOT work for pretty much every user
is a big UI-self-design kit.
--
pippin
---
Philip Meyer;493607 Wrote:
Couldn't agree less. User Preferences are not evil, especially if
presented properly
Not really a philosophy I subscribe to.
http://gettingreal.37signals.com/ch06_Avoid_Preferences.php
--
Luke Redpath
LUKE REDPATH
Freelance Ruby/Rails/iPhone Developer 'for
pippin;493836 Wrote:
Maybe because that information alone is of little help with designing a
UI?
The ONE thing that definitely does NOT work for pretty much every user
is a big UI-self-design kit.
Well actually I disagree (partly). You want the UI to be extremely
usable out of the box but
Phil Leigh;493952 Wrote:
Well actually I disagree (partly). You want the UI to be extremely
usable out of the box but you also want SOME customisability.
Mainly (for me) this is all about menus and nesting structures -
different people have different priorities and want to be able to
pippin;493836 Wrote:
The ONE thing that definitely does NOT work for pretty much every user
is a big UI-self-design kit.
Preferences are good, but an overwhelming UI is bad. FYI, last year I
proposed a simple mechanism for hiding advanced settings in the web
UI
ModelCitizen;472003 Wrote:
For me by far my most common choice when selecting something to play is
whether to play it now, next or add it to the end of the current
playlist so a menu that pops up instantly when I select a playable
item (ala Squeemote) is exactly what I want. On the Touch and
Luke Redpath;493582 Wrote:
I'm afraid you're going to be disappointed by the next release of
Squeemote then; the contextual menu by default behaviour is going away;
the majority of feedback I've had suggests that the old behaviour of tap
to play was preferred.
Good to hear that. It matches
I'm afraid you're going to be disappointed by the next release of
Squeemote then; the contextual menu by default behaviour is going away;
the majority of feedback I've had suggests that the old behaviour of tap
to play was preferred.
Good to hear that. It matches my experience.
The problem
I don't mind tap to play, as long as there is an option to switch
between play/add/play next. The new Controller behaviour for example
would be fine if I could also change the action that happens when you
select a track to add from play.
Thankfully iPeng gets it right.
--
andynormancx
Yes,
Philip Meyer;493607 Wrote:
I'm afraid you're going to be disappointed by the next release of
Squeemote then; the contextual menu by default behaviour is going
away;
the majority of feedback I've had suggests that the old behaviour of
tap
to play was preferred.
Good to hear that. It
Philip Meyer;493607 Wrote:
Touch to play (in my opinion) is evil, so you can add that to your
feedback stats.
Whilst I agree that tap-and-hold should be context menu, touch to play
(esp. if it replaces rather than add to playlist) is just evil. It's
like an operating system having
I've raised configurability as an enhancement request,
https://bugs.slimdevices.com/show_bug.cgi?id=14990.
However this is primarily aimed at Squeezeplay with buttons and IT with
buttons rather than the OP on Touc actions. Please vote if you agree or
suggest alternatives if you don't.
--
Philip Meyer;472307 Wrote:
I understand that people want different things. Some people want to
play/add songs, others don't. Therefore there will never be a
one-solution fits all. That's why some degree of configurability is
necessary, or half of users will be unimpressed with the
DigitalMitch;472533 Wrote:
Totally agreem, Configurability is the key, which in a long winded way
is what I was saying.
[snip]
7.4 has really damaged the use of the IR remote. I expect the IR remote
to do the same thing when pointed at any IR-capable player (that is
consistency) but if
ModelCitizen;472003 Wrote:
For me by far my most common choice when selecting something to play is
whether to play it now, next or add it to the end of the current
playlist so a menu that pops up instantly when I select a playable
item (ala Squeemote) is exactly what I want. On the Touch and
chroma;472758 Wrote:
Agree with this. I also am in support of a fast double-click to play
now on the touch interfaces. Its annoying each time i want to play
something to have to hold and wait. it is useful sometimes. but not in
the normal case.
Unless something changed, a fast single tap on
Phil Meyer Wrote:
I also have the fear that beta testers views are not taken seriously
these days; users from focus groups are more instrumental in the future
direction, and logitech managers are enforcing particular developments
without first listening to feedback.
I agree with most of your
pippin;471888 Wrote:
I _HATE_ these intermediate menus.
For me by far my most common choice when selecting somehting to play is
whether to play it now, next or add it to the end of the current
playlist so a menu that pops up instantly when I select a playable
item (ala Squeemote) is exactly
Thinking this through, it is all driven by the introduction of touch
screens which significantly reduces the available buttons:-
Some functions are not sensitive to where you are in the menu
structure, i.e. play/pause,ffwd,rew and back. and these can be managed
through on-screen touch buttons.
For me by far my most common choice when selecting somehting to play is
whether to play it now, next or add it to the end of the current
playlist so a menu that pops up instantly when I select a playable
item (ala Squeemote) is exactly what I want.
For me, I hardly ever Play, Play Next or Add
Pure consistency can only be maintained at expense and rationalisation
of past functions.
Consistency isn't important across different players/interfaces. Interfaces
should make best use of the features it has available. The IR Remote has play
and add buttons, so they should always work as
God that's so horrible.
I am beginning to despair of this ui stuff. What was a very powerful
and usable ui (albeit with some eccentricities) seems to have been
replaced with one that is counter-intuitive, convoluted and much less
useful.
MC
--
ModelCitizen
Think the third party Squeeze
ModelCitizen;472003 Wrote:
On the Touch and iPeng interfaces I find that far too often I am forced
to hold an item down for a second (or more) to get the result I need for
common actions.
On iPeng you don't need to hold. You can toggle the mode. Don't tell me
you are continuously switching
Philip Meyer;472312 Wrote:
Consistency isn't important across different players/interfaces.
Interfaces should make best use of the features it has available. The
IR Remote has play and add buttons, so they should always work as such
on items that are playable. Therefore there's no need
No, it doesn't *just* make the IR remote less useful, it makes it
more likely that I'll foul up my playlist on a new player since the
new player IR UI has the awful right=play behavior. Less useful would
be an improvement.
Les useful, in that I wouldn't use it as much.
But yes you're right - I
haven't access to a Touch, and therefore don't see how a context menu is
called up, since there are no buttons. I guess touch is play and tocuh
and hold is context??
For other control methods (IR, SBC or on device buttons - Boom/radio)
then there are clearer button options i.e. play, + and then
I keep seeing endless complaints about 'touch to play' behavior. Where
exactly is everyone seeing this?
When browsing, I don't see it above the track level. So is it the
behavior at the track level that everyone is whining about? Seriously?
--
JJZolx
Jim
JJZolx;471498 Wrote:
I keep seeing endless complaints about 'touch to play' behavior. Where
exactly is everyone seeing this?
When browsing, I don't see it above the track level. So is it the
behavior at the track level that everyone is whining about? Seriously?
Dunno - on my Touch a
Of all the devices I use for the Squeeze system the one that has the
best implementation of this touch to play stuff is Squeezemote for the
iPhone. It always asks you:
* Play
* Play next
* Add to end
It is the clearest, simplest, most immediate and least confusing of
*all* the Squeeze
DigitalMitch;471485 Wrote:
I think a wider solution is needed to provide consistency for those of
us with multiple player types to keep us sane. The Touch will provide a
new mechanism (touch) but if using an IR why should it behave
differently from an SB3/Boom. I understand that there is a
I agree completely. At this point the only solution for those of us
driven crazy by the inconsistency is simple: stick with SqueezeCenter
7.3, and don't buy a Radio or Touch player.
Well, I've kept up to date with the latest beta versions (currently 7.5.0), and
I survive because my classic
MeSue;469679 Wrote:
Instead of having the center button (SBC), knob (Radio), or touch
(Touch) immediately play an item, how about if it showed a very short
context menu with just:
Play now (replace)
Play next
Add to end
Then when you just want to play something, you can still do it
I _HATE_ these intermediate menus. They are fine for context stuff, but
they completely put me off for regular use.
I agree.
Putting the Song Info into the context menu, so that touch plays the song
completely puts me off using the Touch/Radio interface for navigation/browsing
my music
Instead of having the center button (SBC), knob (Radio), or touch
(Touch) immediately play an item, how about if it showed a very short
context menu with just:
Play now (replace)
Play next
Add to end
Then when you just want to play something, you can still do it quickly
with a double click or
MeSue;469679 Wrote:
Instead of having the center button (SBC), knob (Radio), or touch
(Touch) immediately play an item, how about if it showed a very short
context menu with just:
Play now (replace)
Play next
Add to end
Then when you just want to play something, you can still do it
68 matches
Mail list logo
