Indenting HTML: WHY!?

The problem with creating pretty HTML that’s indented nicely is that it’s a language that can’t really be indented! It sometimes have an affect on the actual look of the page.

For instance with a <pre> tag, trying to indent that nicely with the rest of your page will make the output shifted massively to the right. The only way to fix it is to have the pre tag the only piece of the source that isn’t indented, which looks uglier than having no indentation at all.

Which inefficient weirdos are debugging by looking at their source and not using Firebug anyway? In your editor you should have “highlight matching tags” turned on. It adds completely useless characters to the page, which are literally invisible. You’re paying for those bytes, and the user is being made to wait fractions of seconds (which Google ranks you on) longer.

Just stop doing it!

Playing MP3 Files In Every Browser

I’ve been looking into various ways of being able to playing MP3 files within the browser, trying to avoid using Flash. Spoiler alert: You can’t do it just yet.

I’ve ended up using another player called jPlayer. (Demo on my prototype page.) It’s a jQuery library which uses HTML5 where ever possible but is able to fall back to Flash if it’s needed, like in Firefox.

The Flash player is invisible when you end up using it, and you control it entirely through the Javascript, which means your UI can be however you want it to look.

I was raving about jsMad, but it doesn’t look like it’s up to the task just yet. The people behind it are planning to spend more time on it in the future though, so that’s definitely exciting.

An Example of Ambiguous UI

Bad UI: What the hell is this?

I had to install Opera to test something out, so this is the first time I’ve actually ever used it.

I’m testing the <audio> element, and for some reason I just assumed that this slider was an audio slider. I thought “oh, that’s quite smart actually” (there may be audio playing somewhere on the page, but you’ve no idea where, so just use this global or tab-wide one), but no it’s actually a zoom slider.

Who on earth uses zoom so much that it needs to have its own unlabeled part of the UI?

The Importance of Tooltip Wording

I was in a non-technical lecture last week (on entrepreneurial idea generation) and the lecturer wanted to show us a video to kick off our session. (It was actually an amazing Steven Johnson video, Where Good Ideas Come From.)

What interested me, probably on par with the video, was the way the lecturer tried to get the volume fixed to play the video.

She was setting up the laptop, got to the Youtube video, and said, before starting, “the trickiest thing about playing videos in lectures is getting the sound to work usually.” So we can deduce that this is a problem she has usually.

She made sure the laptop’s volume was turned up – she was fine with that. Then it came to the volume on the Youtube video. When you hover over the volume button this is what you see:

The volume control rolls out (as it should, to hide unnecessary parts of the UI to make it less complex), and the tooltip you see says “Mute”. The lecturer made sure the volume slider was knocked all the way up to 100%.

And here’s where she got confused. She clicked on the volume button.

Everyone in the lecture theatre (largely just 20 year old students, all bought up with the Youtube interface) blinked at her, a little confused. Someone said “You need to click the volume button again, to unmute it.” And she said “but then the tooltip says that it’s muted…”

What had happened was that she saw the tooltip and read it as the current state: “Mute”. So clicking it again would change the state to unmuted, in her mind. It completely make sense, if you think about it. The tooltip here, being both a verb and an adjective, makes its action ambiguous.

All of the YouTube interface uses verbs as the tooltip, so you’d think that would have made it obvious that the ‘mute’ text was also a verb. But it looks like that isn’t enough to be completely obvious.

Maybe tooltips should be more descriptive.

 

Week 3 in Sound Tiger Development

This week, I’ve not put the hours in I wanted to. That’s probably why there’s no “week 2″ update.

After learning more about the licensing (see last post), I’ve decided I’m going to risk it and just use getID3, the GPL library. Which means, for now, Sound Tiger is all under a GPL license. Not that there’s any code around yet anyway.

Grabbing ID3, or whatever other meta data I can, is relatively painless now.

I have run into the issue I expected with streaming MP3 audio though, with Firefox. I’m looking into jsmad at the moment. Though, there’s no documentation for it, and the code base is larger than I want to dig through. I’ve also no idea where the player is initiated on the jsmad homepage, so can’t just look through the source (no idea what I’m looking for).

There’s also an issue with jsmad when the tab playing music is in the background. The sound stutters. I expect that’s because Firefox gives tabs in focus more demand of the JS cycles. Apparently this should be fixed when audio workers are installed (don’t know when).

I have the database table designs done now too.

I’ve not had any time to work on a mock UI so far. Which is a week (almost two) I’m behind on that particular item. That’s happened because the ID3 data and MP3 streaming both had issues with them (licensing issues with ID3, and technical with streaming) which meant I’ve spent most my time trying to work around those.

Licensing and Ownership around University Projects

This information is specific to De Montfort University, and may not apply to others. It’s quite likely though.

This is something I was curious about at the start of my project, and have only now really looked into it because my project will have to be released under a certain type of license.

In order to get track meta data, I was hoping to use a third part library. The only one I’ve come across for PHP is getID3(). The issue is that it’s under a GPL license. That means that if the library is integral to Sound Tiger then the rest of the source needs to be GPL too.

It is integral: without this library I won’t be able to display meta data (album title, track name, artist) for tracks which makes the software essentially unusable. Rewriting this library wasn’t something I was planning on doing, though may do so in the future, just not for at least six months.

I’ve no issue with making my project GPL compatible. However, I wasn’t sure if I had the authority to make it so.

The contract relating to intellectual property rights concerning student software as part of their course says that the university is the sole owner. This means that I don’t have the right to apply GPL.

I emailed a few people and ultimately ended up in an impromptu meeting with a gent from ProspectIP, who give advice to students about IP matters. I learnt that that clause I mentioned about isn’t always enforced – in fact it’s often considered that the software (or anything a student produces) remains with them, but the university still gets first dibs on if they want to take a stake, and reserve the right to.

The university will only really step in to help secure the IP, and at most take a 50-50 profit share. Though that’s only likely in cases where a large amount of money is about to be made. Something like Sound Tiger, which I don’t expect to make a living off if I ever do sell it, won’t be of much interest to them. There’s not much academic value in my project to interest them either, likely.

So it’s looking like this is less of an issue. I shall bring this up in my next meeting with my supervisor, and seek permission to use GPL’d code in my software.

With the future in mind though, I will be keeping a separate non-GPL version for potential commercial sale.

Week 1 in the development of Sound Tiger

Just a quick run down post for what I did with my ten hours or so during week 1 of the year.

Sticking with my gantt chart, I spent the week analysing and reading a lot about user interface and user experience design.

There’s a lot of small aspects of design which people have put entire research in to, like a journal I read looking into if right handed people respond better when you treat their mouse as if it’s their right hand, and so have controls on the right hand side of the screen (they do).

After reading a few of these journals with their ideas, I decided to test them out in the real world and had a few of my friends fill out a questionnaire I made in a few hours. I got feedback which was sometimes a little surprising; almost everyone had bought music from within their media player (I was curious if a piece of software which has always been a media platform can easily translate its business model into a sales platform – they can, apparently), people rarely use album art as visual aids for navigation but they do still like to have them around to add colour to the player.

As a programmer — especially one who’s just read “don’t add useless parts of the UI” in many journals — finding out that some elements just don’t fill a purpose make me wonder why they’re still there, cluttering up the UI. Specifically here I mean the “genre” attribute. I know for definite that all my genre list either says “alternate”, “alt rock”, “alt” or is just blank. Most people agree with me, when asked how they felt about the genre column the majority responded “it’s almost always wrong”, or that it doesn’t affect what they listen to. Why is it still there? It’ll be off by default in Sound Tiger.

I’ve also seen how important it is to spend time writing a good questionnaire. Previously it’s been a method thrown together to look like you’ve done some research, and so I approached it the same lackluster way this time around too. I wrote in my natural voice, which is often leading. That meant the questions were biased where they should have been neutral. Although there was always an “Other” option, with a plain textfield alongside it, leading questions could be why the answers were often so uniform.

All my conclusions about my research have been talked about in my analysis of current media players. This isn’t complete to the standard I’d like it just yet. The Gantt chart overlord still says I have a week left, though I doubt it’ll change too much.

This week, I’m more excited since I’m actually getting down to technical stuff.

The project timetable for this week has me designing ERDs for the database schema for storing meta data about the music. I’ll likely start on some class diagrams too, specifically for each track, album, and artist.

I’ll also be doing some research into how I’m going to get audio to stream to the browser. This’ll have to be MP3 files predominately, in Firefox 6, IE 9, Opera 11, Safari 5, and Chrome. I know that there will be some licensing issues with MP3 amongst some of the more cautious browsers, so I’ll have to look around for ways around that.

Risk analysis

An important part of the development process, and especially at the start, is keeping an eye out for issues that could arise. And then just to be one step a head of the game, decided how you will get over those hurdles once they do come.

Hardware failure or loss of data is a constant concern since there are so many variables which make them so likely. It’s actually surprising how few cases of data loss I’ve come across. Between losing a flash drive, or a hard drive dying, or burst pipes destroying my machine, and the many hundreds of other ways which data can be lost, it’s always important to have a back up.

To guard against this risk though I’m using a distributed version control package (Git) to keep my code (and all my course docs) in a number of places, and all synced up at any one time. I have a repository on my laptop, on my desktop, and on my server. My server is hosted with AWS, and so is redundantly backed up by Amazon all over the world. To guard against bad administration of my server, and losing data that way, I have various snapshots of my server which I take once a week and keep for a month or two.

Another unlikely but constant threat is prolonged illness which means I can’t get work done on time. To avoid this I could make some lifestyle changes, like eating more fruit. However, if I do fall ill I have given myself a week at Christmas, and almost three weeks before the deadline which are empty on my Gantt chart. This time could be used to catch up.

An immediate risk is to do with the legal and technical issues around having the browser play an MP3 file. I’m not sure if modern browser support the playing of MP3 encoded audio files. This is an important issue since the majority of people keep their music in that file type. Without the ability for them to be listened to Sound Tiger will be almost useless.

Some quick research tells me that Firefox (my main browser, and so the one I most definitely wanted to support) doesn’t intend to add support for MP3 files. MP3 is a patent encumbered file format, but as is GIF and that’s still supported in every browser. Nevertheless, Mozilla have decided against adding support. There are javascript based tools to bring MP3 playing abilities to Firefox though. That means I’ll have to rely on the support of a third party library.

I’ve given myself a week of research time into the methods of playing audio though, which will including experimenting with that javascript library. If at the end of that week I haven’t been able to work out how to play MP3 files in Firefox I’ll have to withdraw support for it (as a user, and for Sound Tiger). Another way around this would be to attempt to convert the file formats into a more open format on the server, once a user uploads their music.

Ignoring the fact that I might not be able to use MP3 files for a moment, simply playing the files could be considered a risk to the project. The <audio> element, which would be used to avoid using Flash, is still fairly young both in the specification of HTML5 and in support for it with browsers. At any moment, a browser manufacturer could decide to withdraw support for it.

This isn’t very likely however. Other the past few years, most noticeably with Internet Explorer, browser creators are beginning to see that the way forward is a standardised web, rather than a competitive one. More browsers are happier to follow the standards set out by W3C. The likelihood of W3C removing the audio element is almost zero; and even if they did, the committee works so slowly there would be discussion of its removal for many years before anything actually happens.

I thin support for the <audio> element will only get more widespread, rather than revoked.

In the unlikely event, a contingency for this would be to use Flash, however. Despite the fact that I really wanted to avoid using it, as much is said in my project contract, it will be the ultimate fall back. This is also the case for if there is really no way to have Firefox play MP3 files.

All in all, I think those issues aren’t likely to crop up, and if they do I have thought out contingencies which will allow the project to be finished by the deadline.

Project Management: Issues With Flying Solo

I’m part way through reading two books; Inside RAD (US), and Paper Prototyping (US).

Both these books offer really interesting ideas about the development process of software.

Inside RAD talks about rapid application development – making a piece of software in 90 days or less. This fits my project perfectly, since I wanted to have two release iterations of ninety days each anyway (I have until April, so that works out pretty well). It’s a quick, agile method which I’m really attracted too.

Paper Prototyping deals with the novel idea of having actual paper versions of your user interface, and then getting a few actual users to “use” the application in the medium. It allows you to see what a user is expecting to happen when they “press” a certain button, or see their flow of actions when you ask them to do something. You get all this user experience research before having even written a line of code. If you need to change something, you just rub it out and sketch in a new design whilst the user is still sitting there!

The issue I’ve come across with both of these methods though is that they are tailored for a group of people working on the project. RAD requires meetings and discussion from a number of people who are experts in their role, and then a scribe to take minutes. Paper prototyping requires a person to watch the user, and give instructions, and write down their actions, and also someone to act as the “computer”.

Whilst the ethos of both these methods will definitely help my project, and lessons will be learnt, actually putting them into practice needs to tweaking or outright rewriting of the techniques.

Regardless though, I’m planning on doing some paper prototyping in early December. I’ll likely have to train a friend to be the computer, whilst I take lead. I’ll also be sticking to the two 90 day iterations.

Final year project: Web based audio player

Final year of university has arrived, and with it comes the final year project (in place of the standard dissertation other courses have).

I’ve decided to create a browser based audio player, much like Grooveshark, however the user stores all their music, and the application, on their own server. Avoiding using Flash, I want to only use the new HTML5 APIs for handling audio and web sockets.

I’m planning to be pretty open about the entire development process, and the software itself. I’ll be blogging about it on here, so this blog maybe fairly swamped with weekly (at least) updates about that.

The application will be largely free, at least until the end of development (when I have to talk to the university about who owns the rights to sell the software), so I’ll be releasing development builds as often as new features get working.

I’ll also be writing about my research into streaming audio from a server to a browser, design, and user experience.

I’ll be calling the application Sound Tiger. Not sure if that’s a permanent name, or a temporary one though.

I’ll be keeping course documents in a folder on my web site.