First Pass GUI Design (first time contributer)

[hanoldaa]

Hello,

I am new to beets and the open source community and was looking to get involved as part of a software engineering course. A few of my group members have posted on the issue tracker with bug issues, but I thought I would go in a different direction. I saw that in the Hacking portion of the wiki you had mentioned interest in a GUI design since beets is currently command line only. I have worked a little bit with GUI at my internship and thought it would be something fun and different to get involved in the design process.

My idea with the GUI implementation is that it would help attract users who might otherwise be put off by the command line aspect. I saw it working with the option to be used as an "introductory" tool, where the various GUI elements would essentially build a typical beets command behind the scenes and execute it. When the user steps through the GUI, there could be an option to display the beets command that they have generated based off their GUI choices in the hopes that, in the future, they can forego the GUI and work exclusively in command line.

As for the actual design, this is a complete shot in the dark, using free (for personal and commercial use) mobile GUI assets that I found online. I figured the best way to get feedback would be to have an example from which changes, approvals and disapproval could be made. Since I am still new to beets and have not had a whole lot of experience, the various views may or may not make sense for the commands they're trying to build. I look forward to receiving your feedback (even if you hate it =P)!

I thought this sort of feature may also make it easier to have different "users", with their own libraries and configurations. Such a thing may already exist, I have not encountered it myself though.

[sampsyo]

Thank you for taking an initial step in this direction! It's great to have someone thinking about UI design issues. I especially like the motivation to let people transition to command-line interaction later after they learn first with the GUI.

Could you please write up some thoughts in text to help put each of these screens into context? What is the user supposed to do in each one, how do they navigate them, and what does each element do? Background on your motivation for each choice will be especially helpful. Comments here or a new wiki page would both be good homes for this information.

[hanoldaa]

(Sorry for the late response - been a busy past few weeks)
I met with my team to discuss the GUI side of things and we are going to split up the responsibilities into 1) creating the GUI and 2) documenting it and textually describing the flow. I toyed with the idea of creating a simple web app with no functionality behind it, just something to be able to play around and test the flow/comfort of the interface. We will be working on that for the next couple of deadlines, so until then, I'm glad you liked some of the ideas and thanks for the feedback!

[alphapapa]

I hate to be a wet blanket, but these mockups are not suitable for a project like Beets. They don't resemble any standard UI layouts or widgets in any way. They don't bear any resemblance to existing music library software.

I recommend that you take some time to study existing music library software. iTunes is not a great example, but it's a prominent one you should have at least a passing familiarity with. I recommend looking at others like Amarok, Clementine, Rhythmbox, and good MPD clients like Cantata. And I recommend that you take the time to actually use them: put together a small sample music library, choose some common tasks like importing, retagging, renaming/moving files, searching for tracks based on different tags, creating playlists, etc, and learn how to do those tasks in each program you study, using your sample library.

After you've done that, you should probably take a little time to look over some existing GUI design guidelines. I'm not a fan of Apple, but they have some good ideas here (or they used to). GNOME 3 seems to have gone off the deep end, but you might look at some of the GNOME 2 guidelines. I don't know how coherent KDE's guidelines are, given the variety of KDE-based UIs, but KDE and Qt are powerful, and I recommend looking closely at them. And as far as very basic principles, even Microsoft's guidelines are probably something you should look at (at least, the pre-Windows 8 ones).

After you've done that, you should have a general idea of how an interface should work for common tasks, and you should be in a position to make some good mockups. :)

[stefancrain]

I would like to second what @alphapapa has said, studying existing music software look and feel is indispensable. Users like what feels comfortable and familiar.

Tools like balsamiq will help you quickly design application processes and share those mockups without worrying about theme and colors.

I think its worth mentioning that there are a couple design guidance & peer review communities that have helped me in the past.
Dribbble: Music Players, Tagging
Forrst: Music Players, Tagging

I might have missed a couple, but those two I personally found the most helpful.

[hanoldaa]

So after reading your comments, I realized that I was pretty hasty in doing the mock-ups and definitely don't have the design experience to jump in headfirst. I figured rather than worry about the design first, I could draft up some UML Activity diagrams that others could critique or use as a base to design an interface. I have only done diagrams that reflect the import, list and move commands. The diagrams do not necessarily include all of the options available for each command, reflecting a sort of "Beets Lite" program to help familiarize users with the program so they can move to the command line.

To go over the import activity diagram: When users select the import option, the first thing they will be asked to do is select a path from which to import. If it's valid, a file preview will update reflecting the files that will be affected, the basic import command will be generated with the selected path and users will be able to toggle three different options: -c, -w, -a. When the user is finished, the the basic import command and all of the tags will be formatted into the proper beets command and executed.

I hope this isn't too far off base and can be useful to some. I will definitely check out those resources once I'm done with school. I'm a huge fan of dribbble and never thought to use it for guidance. Thanks!

[jonathanthomas83]

I'm sorry to jump on the band wagon, but I have to agree with the guys about doing some more research. Primarily research about users and requirements. I don't however, buy into the idea of basing a potential GUI on existing software. iTunes and others, as has been mentioned, are flawed in many ways. I strongly believe that with strong research and requirements based on user needs with a starter for ten being the Minimal Viable Product, we can start to deliver a great GUI (we're talking a web app right? The above looks like a desktop app) and iterate on that.

I am happy to start producing wireframes for what elements should sit on the screen, but I'm yet to get any requirements back from anyone - I sent this out a few weeks back https://groups.google.com/forum/#!msg/beets-users/YXz-LAfQrRs/9yhroO5WLc4J

I have started a wiki page to help us get on track which will hopefully give better definition to the job at hand. https://github.com/sampsyo/beets/wiki/Beets-Web-UI

[sampsyo]

Thanks for starting the wiki page! I may get a moment to contribute there sometime soon—in the mean time, let's use that to collect use cases.

[jonathanthomas83]

No problem, I'll add use cases as a heading. Hopefully between that and user needs, we should get a good idea of what's needed.

[alphapapa]

Why create a new GUI from scratch? Why not use existing MPD clients? Seems like a solved problem. Unless you just want the exercise... :)