Overall impression of stability and usability

Discuss the development and future direction of Play.
User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Overall impression of stability and usability

Post by sbooth » Sun Apr 29, 2007 3:43 am

It seems to me that Play has come a long way in the past few months. I am considering putting out a stable release (Play 0.1) in the near future.

Is there anything in the current svn revisions that people feel should be fixed prior to a stable release for general consumption?

RonaldPR
Posts: 433
Joined: Tue May 30, 2006 8:27 am
Location: Amsterdam, Netherlands

Post by RonaldPR » Sun Apr 29, 2007 11:52 am

I see one possible usability problem for users who have not followed discussions in this forum: There is no obvious indication about the difference between the upper part (the Play Queue) and the lower part (the Library). It is much better now with the split window, but it can still confuse a new user.

Remain
Posts: 37
Joined: Sat Mar 03, 2007 7:57 pm

Post by Remain » Sun Apr 29, 2007 4:36 pm

^ Seconded.

Perhaps for now, just put the text "Play Queue" and "Library" (or what's selected in Browser) above each list,
at least until a better solution crops up.

Oh, and perhaps add Play/Pause, Stop, Previous, Next to the Dock icon's context menu (like iTunes and Cog).
I think that shouldn't be too difficult.

RonaldPR
Posts: 433
Joined: Tue May 30, 2006 8:27 am
Location: Amsterdam, Netherlands

Post by RonaldPR » Sun Apr 29, 2007 7:01 pm

Remain wrote:Perhaps for now, just put the text "Play Queue" and "Library" (or what's selected in Browser) above each list,
at least until a better solution crops up.
That may not be enough. Because of its unusual interface, Play needs at least a minimal manual that explains the essentials about how Library and Play Queue work and how they relate. Could be accessible through the "Help" menu.

Remain
Posts: 37
Joined: Sat Mar 03, 2007 7:57 pm

Post by Remain » Sun Apr 29, 2007 8:18 pm

How about this for an idea:


Image


This can do 2 things:

1) The arrow pointing upward shows the user that the list above it is the Play Queue.

2) It serves as a button for the "Add to Play Queue" action.
And this way, the arrow once again shows how the file is added
from the bottom list to the top one.

Sure, it does not explicitly tell the user how everything works and what is what,
but at least it gives a fair indication (without too much space too).


What do you think?

RonaldPR
Posts: 433
Joined: Tue May 30, 2006 8:27 am
Location: Amsterdam, Netherlands

Post by RonaldPR » Sun Apr 29, 2007 10:17 pm

Hm, this gives some information but it uses little less space than extra labels and it adds a ugly interface item to the existing possibilities of double clicking, dragging, using contextual menu or command-+ key combo. Users may initially think that they need to use this button always. I do not think this is a good idea.

Isn't it possible to have the text labels "Play Queue" and "Library" inside the lists when they are empty?

Paul Gotch
Posts: 23
Joined: Mon Oct 30, 2006 10:54 pm

Post by Paul Gotch » Sun Apr 29, 2007 10:50 pm

Is it possible to read the extra info that iTunes uses to make AAC play gaplessly or will Play only be able to play true gapless formats gaplessly?

If it is possible I think it should be implemented before a 1.0 release is declared.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Mon Apr 30, 2007 12:48 am

Paul Gotch wrote:Is it possible to read the extra info that iTunes uses to make AAC play gaplessly or will Play only be able to play true gapless formats gaplessly?

If it is possible I think it should be implemented before a 1.0 release is declared.
As much as I would like to have a feature like that, I don't think it should be something to hold a 0.1 release on.


I do have some minor things, especially considering a stable release would see a larger and possibly less experienced userbase:

* I think the use of the word 'stream' instead of 'track' or 'song' is confusing. 'Stream' is usually used for streams as in streaming radio. When I right-click on a track in the queue I can choose "stream information" which is actually just 'file info' for that specific track.

* Make sure Sparkle is set up correct before going live. Autoupdate is on by default and on every start up every user will be informed of this "Play 2.0" that is available as update which actually doesn't exist yet.

* I think it is a bit odd to name MP3 just "Layer 3" under Format. I'd say either "MPEG1, Layer 3" or (preferably) just "MP3". Much clearer for most people.

* Maybe do a complete checkout of the latest TagLib from SVN, if you're not using the most recent one already.

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Post by sbooth » Mon Apr 30, 2007 3:31 am

This is a reply to multiple messages, so hopefully I won't miss anything.

I've checked in changes that make the window look like this when the queue and/or library are empty:
Image

I think this makes the functionality more obvious.

Regarding gapless AAC, I'm not sure this is likely with the CoreAudio AAC decoder. Perhaps if I wrote my own AAC decoder (using faad?) this would be an option. Currently Play supports gapless for LAME MP3, Vorbis, FLAC, PCM formats, and Apple Lossless.

Regarding stream vs. track or song. This is a good point. What is more intuitive to most people: the term "song" or the term "track"? I would lean toward track, because although track implies more than is necessarily true, many audio files (e.g. concertos) are not songs, so track seems the better of the two choices.

Regarding Layer III vs. MP3, I can see your point. My intention with the format and type is that type is the type of file container, such as Ogg, CAF, or whatever, while format is the format of the audio data. So for Ogg FLAC and native FLAC files, only the type differs. The format of both is the same- FLAC. With MP3, the file's type is MPEG Audio (MPEG-1 audio I suppose), while the data format is Layer III. It is possible to have Layer II and Layer I in that container type as well. That being said, most users are oblivious to this. I could possibly go either way, although I prefer the way it is now.

Play uses an updated (and patched by me) version of the TagLib svn.

Getting Sparkle up and running is obviously a given.

RonaldPR
Posts: 433
Joined: Tue May 30, 2006 8:27 am
Location: Amsterdam, Netherlands

Post by RonaldPR » Mon Apr 30, 2007 8:52 am

sbooth wrote:I've checked in changes that make the window look like this when the queue and/or library are empty:

I think this makes the functionality more obvious.
This is what I meant. This will hopefully help users to understand how things work.
Regarding stream vs. track or song. This is a good point. What is more intuitive to most people: the term "song" or the term "track"? I would lean toward track, because although track implies more than is necessarily true, many audio files (e.g. concertos) are not songs, so track seems the better of the two choices.
It could be either track or song. I think it should be track. Although tracks are often referred to as "songs", many tracks are in fact not songs. "Streams" is wrong, it refers to streaming via a network, not to files or tracks.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Mon Apr 30, 2007 1:10 pm

sbooth wrote:
Regarding gapless AAC, I'm not sure this is likely with the CoreAudio AAC decoder. Perhaps if I wrote my own AAC decoder (using faad?) this would be an option. Currently Play supports gapless for LAME MP3, Vorbis, FLAC, PCM formats, and Apple Lossless.
FAAD is actually a pretty decent decoder, when talking about features. It support more than just the AAC-LC profile that CoreAudio supports at the time. I believe there is some license controversy about it though. When the time comes to think about implementing it, I think we should have a separate topic on FAAD to discuss this.
Regarding stream vs. track or song. This is a good point. What is more intuitive to most people: the term "song" or the term "track"? I would lean toward track, because although track implies more than is necessarily true, many audio files (e.g. concertos) are not songs, so track seems the better of the two choices.
I vote for 'track' too.
Regarding Layer III vs. MP3, I can see your point. My intention with the format and type is that type is the type of file container, such as Ogg, CAF, or whatever, while format is the format of the audio data. So for Ogg FLAC and native FLAC files, only the type differs. The format of both is the same- FLAC. With MP3, the file's type is MPEG Audio (MPEG-1 audio I suppose), while the data format is Layer III. It is possible to have Layer II and Layer I in that container type as well. That being said, most users are oblivious to this. I could possibly go either way, although I prefer the way it is now.
I see your point. How about showing both container and format? Container first, format second. [MP3 / Mpeg 1, Layer3] or [Ogg / Vorbis] or [Ogg / FLAC] or [M4a / AAC] etc.

The average user will just want to see the container name because he or she will not know the difference. People who want to see both can widen the 'format' column to show both. I agree it is interesting info for the power user, it is just a bit confusing for the average one.

Some extra points:

* Is there a specific reason to have 'Stream/Track information' and 'Edit Metadata' as two separate forms/windows? Most programs use a single option showing both editable and non editable metadata. In a way, number of channels or bitrate is a form of metadata as well, though un-editable.

* When I add a Watch Folder, the OK button stays greyed out. Pressing enter works. Just can't use the mouse to OK it.

* It may be an idea to make a separate low priority thread/process of the Watch Folder scan. When using a larger folder (1000+ files) it consumes all processing power and makes the whole system practically unusable. This is on a G4 so it may be better on of the new multi-core CPU's.

* How about an option to edit existing 'Watch folders'

* Since a few days/builds Play hangs when harvesting a specific newly added Watch Folder. After Force Quiting Play, I have to trash the DB and plist for it to work again. It may be a very specific issue, I'm looking into it now. Maybe others could experiment with Watch Folders to see whether they can reproduce it as well?

* When I upgraded from an older build to build 695, I had to trash the existing sqlite db, otherwise Play would crash on startup. There may be a need for a conversion or automatic trash of the DB for people coming from older builds.

(Using OS X 10.4.9 on PPC)

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Post by sbooth » Mon Apr 30, 2007 4:11 pm

Maurits wrote:I see your point. How about showing both container and format? Container first, format second. [MP3 / Mpeg 1, Layer3] or [Ogg / Vorbis] or [Ogg / FLAC] or [M4a / AAC] etc.
There is a separate column called type, which is there for ease of searching. This way you can make a smart playlist where the type is Ogg but the format is not Vorbis, etc. They could be combined (they are in the stream information panel), though.
The average user will just want to see the container name because he or she will not know the difference. People who want to see both can widen the 'format' column to show both. I agree it is interesting info for the power user, it is just a bit confusing for the average one.
This may be true, I'll have to mull it over.
Is there a specific reason to have 'Stream/Track information' and 'Edit Metadata' as two separate forms/windows? Most programs use a single option showing both editable and non editable metadata. In a way, number of channels or bitrate is a form of metadata as well, though un-editable.
There is a reason- you can edit the metadata of multiple files at a time, while you can only get info on one stream at a time.
When I add a Watch Folder, the OK button stays greyed out. Pressing enter works. Just can't use the mouse to OK it.
I forgot about this bug, I'll fix it.
It may be an idea to make a separate low priority thread/process of the Watch Folder scan. When using a larger folder (1000+ files) it consumes all processing power and makes the whole system practically unusable. This is on a G4 so it may be better on of the new multi-core CPU's.
Right now the scanning is done in a separate thread. I can set the priority lower, though. To be honest I don't really use watch folders as my collection doesn't really change. They seem to work OK, but not perfectly. Perhaps this is a kqueue limitation.
How about an option to edit existing 'Watch folders'
I will add this as well.
When I upgraded from an older build to build 695, I had to trash the existing sqlite db, otherwise Play would crash on startup. There may be a need for a conversion or automatic trash of the DB for people coming from older builds.
For release to release upgrades, this will be the case.

RonaldPR
Posts: 433
Joined: Tue May 30, 2006 8:27 am
Location: Amsterdam, Netherlands

Post by RonaldPR » Mon Apr 30, 2007 4:52 pm

Maurits wrote:I see your point. How about showing both container and format? Container first, format second. [MP3 / Mpeg 1, Layer3] or [Ogg / Vorbis] or [Ogg / FLAC] or [M4a / AAC] etc.

The average user will just want to see the container name because he or she will not know the difference. People who want to see both can widen the 'format' column to show both. I agree it is interesting info for the power user, it is just a bit confusing for the average one.
I would prefer to see in the Format column only the label that is most often used and that is familiar to the average user, even when it would be technically not entirely correct or complete: "MP3", "AAC (m4a)", "FLAC", Ogg/FLAC, Ogg/Vorbis. More correct and detailed format information about the file can be shown in the information window. Trying to be correct in the format description will confuse ordinary users.

(BTW: A similar problem of confusing users with format descriptions is present in Max when choosing encoding formats. Users do not know that they have to choose "MPEG4-audio" for encoding into AAC and erroneously choose "AAC ADTS" because that is the only choice with "AAC" in it.)

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Mon Apr 30, 2007 9:46 pm

sbooth wrote:
Maurits wrote:
Is there a specific reason to have 'Stream/Track information' and 'Edit Metadata' as two separate forms/windows? Most programs use a single option showing both editable and non editable metadata. In a way, number of channels or bitrate is a form of metadata as well, though un-editable.
There is a reason- you can edit the metadata of multiple files at a time, while you can only get info on one stream at a time.
I see, that makes sense.
sbooth wrote:
Maurits wrote: It may be an idea to make a separate low priority thread/process of the Watch Folder scan. When using a larger folder (1000+ files) it consumes all processing power and makes the whole system practically unusable. This is on a G4 so it may be better on of the new multi-core CPU's.
Right now the scanning is done in a separate thread. I can set the priority lower, though. To be honest I don't really use watch folders as my collection doesn't really change. They seem to work OK, but not perfectly. Perhaps this is a kqueue limitation.
You may want to consider setting the priority lower. You may not use it, I usually only use it for smaller folders, but if Play gains more popularity you're bound to get bug reports on this as I expect a lot of people to actually use it. Maybe even to drag their whole collection in. :shock: And it is rather annoying to lose control over your system because some small program decided to consume all power.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Mon Apr 30, 2007 9:51 pm

RonaldPR wrote: I would prefer to see in the Format column only the label that is most often used and that is familiar to the average user, even when it would be technically not entirely correct or complete: "MP3", "AAC (m4a)", "FLAC", Ogg/FLAC, Ogg/Vorbis. More correct and detailed format information about the file can be shown in the information window. Trying to be correct in the format description will confuse ordinary users.
How about by default having a column with the most familiar name and having an option for a more correct or informative column?
RonaldPR wrote: (BTW: A similar problem of confusing users with format descriptions is present in Max when choosing encoding formats. Users do not know that they have to choose "MPEG4-audio" for encoding into AAC and erroneously choose "AAC ADTS" because that is the only choice with "AAC" in it.)
Yes, I agree, that's why I proposed the use of Preconfigured encoders.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest