Friday, July 30, 2010

Letting the Managers manage


I have now moved a lot of the core code into what I call "managers". There's the MediaManager which takes care of playback, the PlaylistManager which is pretty self-explanatory, along with the FilesystemManager which takes care of finding the tracks and keeping sync with the filesystem, the UpgradeManager which talks to the upgrade server and installs all the new files, and finally the SettingsManager which remembers settings and initializes stuff upon first run.

This makes the code much easier to work with. Having everything separated instead of everything all over the place. But the benefit is not only for me as a code. There's also some nice results here for the users as well. Thanks to this I managed (no pun intended) to optimize the code a bit. Most of the startup time of Yama is spent on 1) initialize the GUI and 2) scan the filesystem for any changes since the last run. I cannot do much about Windows initializing the GUI but I did bring the FilesystemManager up to some speed.

I will do some testing on my other machine which is a bit slower but on my desktop which is equipped with a 64bit Core 2 Duo I have measured a 25% improvement in startup speed. Tomorrow I will be back with a nice graph and some nice numbers to show the improvement on both machines.

The goal is to keep Yama fast and light, so I try to always find ways to improve the startup time and overall responsiveness of the GUI.

Have a nice weekend!

Friday, July 23, 2010

Designing application interaction and user experience


In the middle of some coding on file association and major code cleanup I still have time to reflect over interface design. Not just in the sense of the actual graphical interface but also the design of the experience the users will have with the application.

During the semester starting this fall I will take a course in Human-Machine interaction which will hopefully provide me with even greater insights into the psychology of the average user and how to optimize the interface of the application to make the user's experience with the application as smooth and effective as possible. However, I already have some thoughts on the best approach for my application and applications in general.

The Text
When a user reads the text of an application they don't actually read it, they scan it in order to quickly find what they are looking for. They will only read blocks of text if they find it necessary. With this in mind the text should be short and straightforward. The title should say it all and the description should be brief. Any extra text should be added via a help link in order to further explain a certain setting, term, etc.

The text should also be very light in tone. Treat the user in a friendly and non-technical way. As an example the error messages should be very descriptive (but not too long!) and include a proposed solution to the cause of the problem. The application should be written to always "understand" what went wrong in order to avoid error messages such as "unknown error".

The wording of the text is important. The text should include positive wording and try to encourage the user. Telling the user all the wonderful things they can do instead of telling them what their limits are. It is also important to not intimidate the user via bad wording. For example let them know that they can "create quick playlists" instead of telling them that the application lets them "create quick playlists".

The text should sound warm and encouraging, like a good friend explaining how to perform a certain task, instead of sounding like a mechanical machine or an anonymous corporation.

The Settings
One of the biggest questions when designing an application is what should go into the settings/preferences/options/configuration window and what shouldn't. There are downsides to both extremes. It is not desirable to go the Apple/Gnome way and treat the users as dumb idiots that you can't trust to do things their own way, instead paving a way of how to use the application with electric fences on both sides so that the user can never get lost. This is extremely insulting to people's intelligence and not a good practice. There is nothing wrong in letting the user decide what they want, cause they do know that better they the developer.

However, the other extreme is not ideal either. Puking a massive load of settings onto the unsuspecting user will result in either scaring them off in confusion, or have them tinker and tweak until the end of days, trying to find "just the right setup". But there's another downside: the support will be so much more complex for an application with a high number of combination of settings and preferences. It is never wrong to just go with a certain implementation and move on.

A good balance between the two evil extremes is the best approach. Besides, it is always possible to implement certain settings later on, if it turns out that most users want a certain settings that the developer omitted. It is also always good to do surveys finding out the most and least used features and settings in order to find out if something can be removed or changed. Listen to the users! Don't just release and forget.

The Interface
Human beings will always judge on appearance, at least partially. If something looks good, it will give a better impression. But more importantly, the interface will always be the main portal for the users to interact with the application and its functions. There's many examples on how not to do. Winamp comes to mind. The interface is a mess, a prime example of bad interface design. The interface is extremely cluttered with buttons, labels and controls. To make things even worse the different parts of the interface does not have a clearly and well balanced focus. A music application should focus on two things: playback of tracks and the actual tracks. Creating a good layout of the controls is very important in order to make it easy for a user to quickly find, identify and use the controls, so that they can complete the task at hand effectively.

Continuing the rant on Winamp's horrid interface that looks like something a 14-year old have designed in his mom's basement: it is an alien invading your system. It has one of the worst integration with the underlying operating system. It does not use the default look, making it stand out and feel awkward and out of place. Even if that may be just a personal preferences for most people more importantly the Winamp interface suffers from a great number of accessibility shortcomings. It doesn't have any respect for the DPI settings of Windows, making it very hard to read for visually impaired people who do not wish to decrease the screen resolution just to be able to quickly find their way around their music application. Also, respecting the system colors is important from an accessibility viewpoint.

But not only Winamp is a good example on bad interface design. iTunes follows in the theme of not respecting system DPI, colors and using native controls, window borders, etc. This is very interesting given the fact that Steve Jobs is criticizing developers for not porting their application to Cocoa, or bashing Flash and other third party developer platforms for standing in they way of full system integration and exposing all features of the operating system to the application developers.

Although not related to Interface design, another bad move by the iTunes developers (and many, many other developers) is not using the tools available on the platform and instead requiring users to install extra software. Bundling iTunes with Apple Bonjour, Apple Software Update and Apple QuickTime. Bundling is bad. Use the existing tools instead.

Spotify seems to be impressed by the bad interface of iTunes and tries to mimic it, managing to surpass iTunes on bad interface design. A lot of Qt and GTK application that get ported to Windows also integrates poorly with the system. The situation is a mess.

A number of studies have shown that familiarity is very important to user experience. Blending in with the rest of the system is key to make the user feel at home. Integration with system features is also important. After all, that's what the operating system is there for in the first place, to provide developers with a set of tools to use.

A careful layout with balanced margins and spacing will give the user a feeling of a clean interface, avoiding the impression of clutter and information mess.

The Flow
When someone is using an application they have a clear focus and a well defined flow. There are a number of ways to interrupt that flow. A warning message is one example. The application should do everything it can to stay out of the user's way. Try to solve a problem without alerting the user. One good example is when you launch an application. If we analyze this situation a bit we can quite easily determine what the focus of the user is. If you launch an application you have a clear goal: you want to use it for a specific, well defined purpose. Taking my application as an example the situation may be a party where the guests have demanded some music to be played. The host decides to launch the application in order to start some tunes. A popup message telling the user that they can upgrade the application will be an extremely inappropriate disruption of the flow and most likely ignored. The worst scenario (but not uncommon) is the popup telling the user that there's a new version available and a link to the website.

No, not cool. The application should stay in the background, and automate as much as possible in order to let the user focus on the actual functions (in my case: playing music).

The Focus
The focus of a lot of applications is the application itself. The developers are living inside the application, looking on the world from the inside out. This is often reflected in the communication between the application and the user and will in many cases confuse, intimidate or alienate the user. The developer should always look at the application from the user's point of view, and describe tasks, labels and error messages from the user's perspective. This will create a more friendly tone in the communication and will encourage the user, helping him or her complete a certain task in a more effective way. It will also leave the user with a warmer and more relaxed feeling instead of sounding mechanical or corporate.

Furthermore the focus should be not on features, but on function and tasks. The user will not be interested in looking at pretty gradients and amazing animation (although they have their place in usability design as well), they are interested in completing a certain task at hand. However, they will notice ugly gradients and annoying animations, so the goal is to actually keep the user from focusing on the skin and let them keep their focus on what they want to do instead. Of course, a nice and beautiful interface that is not in the way beats an ugly interface that's not in the way. There's always a place for beauty in our software.

There's a whole lot more to talk about when it comes to interface design, user experience and information architecture but I don't have time for everything right now. However, I will try to keep my focus on creating a great experience and make my application a pleasure to use. Maybe I will have to rethink a few principles but hopefully the end result will turn out great.

Do you have any additional thoughts on the topic? Is there anything you disagree with? Your comment is more than welcome.


Wednesday, July 14, 2010

Settings and about done


As I am testing the upgrade function before I am ready to release it to the rest of you I am implementing features to see if they get pushed out to installed applications.

The first feature that I have just finished is the preferences and about pages. As mentioned in the previous post I tried to make it look like the Control Panel of Windows 7. Here's the result:

General Settings
Music source settings
About Yama

I haven't yet implemented the feature that will use the settings on the "General" page but they will come soon enough. My goal is to have as few settings as possible, since I believe in good default settings and clean interfaces. If anyone wishes to change the interval for checking for upgrades (the default value is once every hour, btw) one is free to just change the code and compile it (just go to this file and edit line 20).

Anyway, so this is what the settings will look like. As mentioned in an earlier post it is possible to control playback while inside the settings pages thanks to the upper part of the window being static.

Next on the agenda will be file association, minimize to tray or an OSD. Haven't decided which one is the most fun yet.

Oh, and as always, any feedback is more than welcome.

Have a nice day!

Wednesday, July 7, 2010

Thoughts on settings


So the upgrade system is now almost finished. The next thing on the agenda will be to implement the settings, about and help. Since the goal of Yama is to be really tightly integrated with Windows my main thought here would be to make it work like the Control Panel.

If you click on the Start Menu, open Computer and click on System Properties you will come to "Control Panel\System and Security\System". I thought that this could be the look of Yama's settings. The upper area will be the normal Yama controls. There will be Play, Pause, Forward and Previous, Seek and so on. This means that you can control the playback even as you are navigating the settings.

The left part will be used as the navigation links. The top link (the one that says "Control Panel Home") will be "Back to Yama" or something similar. Under that there will be "General", "Library", "About" and "Help". General and Library will be usual settings, About will be similar to the screenshot above and provide the user with basic information about Yama, while Help will contain some guides on how to use Yama as well as tips and tricks (such as keyboard shortcuts or quick playlists).

The "See Also" links will be to external websites (which will open in the default web browser). They will be "Website", "Blog" and "Project Site" most probably.

The Control Panel in Windows 7 is quite a mess. It opens new windows and the links to the left changes as you navigate around. This will not be the case in Yama. The left part will be static, always displaying the same links. No new windows will open, everything will be done in the right area (the white one). The only new windows that will open will be when the "See Also" links are clicked to open a web browser.

So that's pretty much how it will work. The reason I want to do the settings this way is:
  1. It will make it really easy to navigate the settings, giving it a clean interface
  2. It will be less intrusive since it doesn't open any new windows
  3. It looks good
  4. It will look more like a natural part of Windows 7
So what do you think?

Friday, July 2, 2010

Feedback on privacy concerns

Hi, all!

I am right in the middle of coding the Upgrade System. I just finished the server side code. It works like this:

The client (Yama) will connect to our server in Canada via HTTPS. This ensures that all information between our server and Yama is encrypted and safe. It also makes it easy to use behind a firewall since most firewalls have the correct ports open for HTTPS to work. In the request to the server Yama will send the current version number and a unique client ID if it has been given one.

If the client does not have an ID it will be created by the server. The server will either send a package back with all required upgrades, or send a message that Yama is up-to-date.

Each request will be logged on the server. The information will be client ID, current version (upgrade from), latest version (upgrade to) and IP address. I will use this information to track the number of active clients out there (the client ID is used for this), and any abuse of the system (the IP will be used for this). Since all my source code is open for anyone it is pretty easy to see how to connect to the server with your own code and try to abuse it (find a security hole or the like).

My idea was to keep the IP address for a period of time and then delete it.

How do you guys feel about this? Is it OK? Does it intrude too much on privacy? The encryption is there to protect you from other people but in the end we will have your IP address, which can be used to track you, on our servers for a while. How long should it be kept? A month?

Please, send me feedback via the comments.