Sam Iles's Blog

Recently I blogged about my method of to-do lists. I was writing on my index cards this morning and I suddenly realised that I could make a to do list website that functioned exactly as I wanted it to, just like the index cards method.

9.34am (I made a note of the exact time, all further times are rough)

I took to my Moleskine and wrote a page of notes about how the site would work, what features it would offer and a quick UI mock-up. I only spent around 20 minutes doing this.

10.00am

I started work right away. I made a new host on my Mac so I could visit and test the website locally at http://todoapp/ and make the database locally and added the relevant tables (the structure of which I’d made in my notes). I added a few sample tasks to the database so I’d have something to look at when testing. Then I made the files and folders I figured I’d need. (So, /login/ and the relevant files and /todo/ for the main app, with a few files including the main app’s page and the PHP files to post the AJAX content to. Then, a nice CSS file to round everything off.

Ready to code.

10.15am

I opened to main app’s page and started adding in the HTML outline and the divs I figured I’d need. I decided to load the overdue tasks and today’s tasks when the page renders (as they really need to be there ASAP) and load all other days incrementally over AJAX. I figured this’d have the best loading time result (load important content first, then the rest) otherwise I’d have thousands and thousands of lines of code for just the one page. Of course, I will adjust and test this properly when I get the chance.

10.30am

Next up, I wrote the SQL queries and code to get and print out the tasks. This involved crafting the queries so they worked correctly and echoing out the data in a nice way, with all the checkboxes and strikethroughs for completed tasks and etc. Then, I wrote the JavaScript functions which are called when the user clicks on the checkbox, which includes the AJAX call itself and returning the relevant data.

I then went to the PHP pages which receive those AJAX calls. Just a few dozen lines of code (much of it copied from other pages as I’d already written it) and those pages were receiving the data, marking the task as done, getting the tasks all over again and posting them back to the home page. The home page then echoes the data it receives (which is just an updated copy of the tasks) into the relevant div.

Doing it like this, when the user clicks a checkbox, the task is marked as complete in the background, and instantly gets crossed through and moved to the bottom of the list, if applicable. This gives a instantaneous, desktop-app type feel, whereas in reality there’s a lot over data being invisibly sent around in the background.

So, after just one and a half hours, I had an app which got the tasks that are overdue, due today or due tomorrow, formats and displays them nicely and marks tasks as done using a pretty complicated AJAX technique.

11.00am

Next up: adding new tasks.

Again, pretty simple here. I made a text box at the top of each day’s div and set up some jQuery to listen the user hitting return (no buttons here!) and then submit the task via AJAX to addtask.php, and print the data (all the day’s tasks) into the div, to give the impression of it being added in real-time. Add the code to the addtask.php file to do that and we’re good to go.

Simples.

11.30am

Next up: postponing a task.

I thought it would be pleasantly simple to click a task’s little green postpone arrow and have that push the due date back a day. No messy “click Edit Task, change the date, click Save”. So, just click the arrow and push it back a day. Simple, right? Not really. This presented a few challenges.

1) I didn’t want to green arrow showing all the time. It would make the page look ugly if it was full of tiny arrows. I wanted them to be shown only when you hover over the task. (That was relatively simple. Just a little jQuery to do the show/hide on mouseenter/mouseleave, while making sure it was taking into account that much of this data would be loaded over AJAX and therefore unbinded.)

2) With adding a task or completing one, I could send the data, update the database, then regenerate the correct list of tasks and populate the div with this. However, when postponing, I need to update both the div that sent to update (to remove the task from its list) and update the div containing the next day’s tasks (to add the newly postponed task to its list). Eventually, I settled on returning the data for the original div in the AJAX request and then starting a new AJAX request client side to get the updated tasks for the next day. If you know what I mean.

So. I coded that.

Blah, blah, blah. Wirte the code. My plan which I just described worked pretty darn perfectly. I had to go back and recode a few lines as I realised I was hard coding some of the variables in rather than using, well, variables which would have resulted in about five times more code for the same task. Other than that, it was all pretty uneventful.

12.30pm

At this point, three hours in, I had what was essentially a working to-do list app. Users could: create a new task on a day of their choice, mark a task as done and postpone a task, all laid out in the unique day-by-day style I wanted.

But, there were still a few features left to add.

First up: adding tasks with a due date greater than eight days away. Obviously, I couldn’t have a card for each day going on down the page for all infinity (“The Never Loading Page” sounds like a great geek horror movie). Even if I could (infinite scrolling could have been used here), it wouldn’t be very user friendly to ask someone to scroll through 365 cards if they needed to add a to-do that was a year away (“Submit Taxes”, for example). So, I needed a text box at the bottom of the page where the user could enter a task’s name and due date, while making that in keeping with the app’s simplicity. Let’s make that, shall we?

I don’t think I’ll add that right now. I’m going for a quick launch here, and this feature really seems too unneeded right now. I put a little disclaimer to explain that it’ll be ready within the next few days.

So instead I added all the CSS I’d need to make the page look at least a little pretty and did the basic formatting such as adding the user email in the top corner, adding a footer and the rest.

For now, that only leaves adding the functionality to create a new account. Very similar to logging in (and using much of its code) it was only a few lines.

While I was on that, I made the page to log out. Just a tiny three lines of code in a PHP file to do that.

1.00pm

It was around this time I started thinking of a name. I didn’t really think much. I just wanted [a word which conveys happiness/simplicity/peace][To Do] and quickly thought of the word Ananda which, along with being the name of the Buddha’s faithful companion, is also a Buddhist term meaning happiness, bliss and joy. It seemed to suit, so I quickly registered anandatodo.com so it’d be ready ASAP. I’m not claiming it’s necessarily a good name or a wonderful one, but it suits my purpose for now at least.

Next up, a homepage! I really can’t be bothered to make something huge here. In fact, I’m just going to throw some text up. I think video is the only way to showcase this app well, so I want to make a screencast type thing with a nice narration to explain it. After all, there are just a few features and the AJAX just make it look somewhat impressive to the eye, if I say so myself. So, I’ll make a video and that can take centre stage in the homepage. So, for now, I’ll just put up an Alpha type page to briefly explain and invite a few people along, for testing more than anything. I also quickly made a Google Analytics profile and added the tracking code so I’d know who’s visiting.

So, code code coding the homepage.

1.30pm

Then, we’re nearly at the end. All that’s left from here is moving the CSS, JavaScript and images off to the CDN, setting up the server and launching!

Putting stuff on the CDN took a matter of minutes. At this stage, I committed all files to git with the message “FIRST COMMIT IS A GO!” and the site was all done.

Firing up the terminal, I SSHd into my server and created the new virtual host and created a copy of the local database on the server and FTPd up the files. Then I added the domain to my DNS records, which propagated instantly.

Aaaaand…

All done!

I’d only registered the domain name an hour or so before, but it was already live. I made a new account on the actual server and did a little testing just in case some URLs had died in the transfer from local to production, but all was fine.

I updated the Smiles Software homepage to include the newest product.

The site was officially available and complete, with the Smiles Software page updated at 2.30pm

I then quickly wrote this blog post.

And that’s it. Ananda To Do: a super simple to do list application focusing on a day-by-day approach, from idea to launch in just five franticly fun hours.

1) Bookmarking tools
2) Email clients
3) Calendar software
4) To-do lists trackers
5) Music managers

How grateful must they be? Me – Sam Iles – is about to give free advice to Spotify.

First off – cost of your service. You’re recent changes to the “Open” service make it, well, crap. The thing I have a problem with is the limiting of listening to each song just five times before it gets locked forever. The point of a free service is that it should offer less than the paid ones while preserving the core experience. This allows people to see what you have to offer. By putting this limit on songs, you damage the core experience, before most people have even thought about the paid option. It goes from being an unlimited service to a perishable, limited service.

If I was running the company, I would have dropped the time per month limit more (to, say, five hours down from ten) and remove the per song limit. The overall limit is abstracted enough that it doesn’t directly affect the service itself – whereas a per song limit does. I think it damages the new comer’s impression of the service.

Secondly – your app sucks. You aren’t going to like what I’m about to say, but: it’s worse than iTunes. For people to subscribe to your service, Spotify needs to become a complete replacement for people’s current music app (invariably iTunes). Many people have gigabytes of music already (from CDs or bought from iTunes). Your app does import local music from iTunes and let you play it in Spotify, but it’s a horrible experience.

As soon as you open Spotify we should see our music right there. Clearly sorted by artists or albums (which iTunes actually does really well, with it’s cover art in the main view). With you, I get a list of thousands of songs. No simple way to search through that or sort it. Not good.

Yes, some people will say to me, “but, Sam, you can make playlists and star things”. But, I don’t want to. I have gigabytes of music and I have no desire to create playlists to manage all my music when I just want to access it.

This is another problem: with music that is actually on the service, there’s no good way to save it. If I want to come back to an album, I have to add it to a playlist or something similar (playlists are for grouping different music with a similar theme, not all the same music). There should be a way to add an album on the service to my album view so I can access it easily when I need (I mean, I am paying £10 per month – I don’t want to have to search for whatever I want every time I open your app).

Another problem: I can’t actually open a particular artist I want and view all their songs easily. If I click on an artist, I get a window with every album they’re featured on. This includes – infuriatingly – compilation albums and the like. At the moment, I am using Spotify to shuffle through songs from Glee, which involves skipping every third song because it’s from the album “Totally Pop” and by artists which I am entirely uninterested in.

Even without these compilation albums, say I try to view Beyoncé. I can’t just view her three albums, but have to look at all her singles, too (duplicating many of the songs and defeating the purpose of shuffle). I don’t want to have a create another playlist for this.

I have even more complaints, but I’ll stop there. There is my worthless advice: improve your app, change your subscription service and then I’l love you…

‘If you are not embarrassed by the first version of your product, you’ve launched too late.’ – Reid Hoffman, Founder of LinkedIn

I read this quotation recently and it really resonated with me. I broadly agree with him. Here’s why.

Feedback is critical to any product. Especially on the web. Websites are so easy to tweak that making a mistake doesn’t matter. But, if you spend a year writing code and taking your product in one direction which isn’t actually what people want then you’ve wasted your time. Feedback from users telling you what’s good, what isn’t and what they’d like to see is so important. Even if you have a handful of users, feedback is still invaluable. Even if “feedback” isn’t words, but just usage metrics it’s still important.

I always try to launch early. I figure that the sooner I have code in people’s hands the sooner I can build a user base and the sooner I can get tangible feedback. Sure, some users will be dissuaded from using your service if they can’t handle the pre-perfectly-designed version, or need some features or can’t deal with a bug or two. But, in the long run, developing a product with constant feedback will always make a better product.

This incidentally, what I intend to do this week. I started making a website on Monday and I am going to get it out this week. It will have the basic features and the basic design and we can go from there. If I can get half a dozen people to use it and offer the occasional comment then I can direct development far better and hopefully make happier users as they see their ideas and thoughts being realised.

So there we have it. A short post to add my thoughts to Reid’s: launch early, iterate often, make a better product.

Cross posted from the Deverous blog

There’s a lot of talk about a second Internet bubble around now. The theory goes that there are more and more Internet companies around which are getting huge amounts of investments and huge valuations when they might not be worth it. Especially when many of them don’t have a business model yet.

Where there is a business model, it tends to be ads. This introduces a problem unto itself. If money doesn’t go into the system, there isn’t enough advertising money to go around. Of course, this is a simplistic view, as there are real world companies (that sell real products) which advertise online. But, if there are one billion websites online all trying to advertise with each other, where does the money come from. This was how the first bubble happened: lots of people rushing to invest in the web and then realising they didn’t have a way to make their money back.

So what does the web need? People to pay for its services? I think so. But, I don’t think the traditional way of paying $39.99 per year is needed. That’s fine for a few services, but few people would want to spend more than even $50 per year online.

So what about micro-payments? I think it would be a great way to introduce a lot of revenue into the system. People are happy to pay for a $0.99 iPhone app. So, why not a $0.99 web service?

Take, for example, Twitter. Let’s say they charge you one dollar to make more than one thousand tweets in a month. Or, Facebook charges a dollar if you want to upload more than one hundred photos. Same for Flickr. Or all these great web services we use for free can charge tiny amounts for a few services. Think of it as in-app payments for websites.

The problem with this approach is the cost. No small (or even large) web company can charge such small infrequent amounts to credit cards without being landed with enormous fees. So, someone needs to help out. Let’s say it’s Google: they say that their checkout service can be highly integrated with websites and easily and profitably accept small amounts, so you just log in as simply as on the iPhone with your iTunes account. A company like Google that did something like this well could make a huge impact and gain huge traction.

Small card charges are possible (think single song purchases on iTunes) but they take the clout of a major company to make them happen. A startup with one guy in his bedroom couldn’t go to a huge bank and try to hammer out some kind of deal.

And the frustrating thing is that these card transactions actually cost very little – if anything – to make. If you think about it, when you make a card transaction online, all that happens is the processing company takes your numbers, sends them to your card company who confirms them and then informs the bank of the amount which needs to be taken out. Thanks to the Internet, this whole process takes a microsecond and doesn’t incur any tangible costs. But, each party involved adds their small fee and it soon builds up.

But, imagine if a company could make this work. Make a great service with a great API and have a minimum of $0.99, with a 10% charge or even 5% (in contrast to Apple’s 30%). There are ways – I am certain – to make money like this. By working with banks, grouping payments over a week or two and pricing low for volume, someone could really clean up. (And I think that service could be Jack Dorsey’s Square). Even the 30% that Apple charges wouldn’t be that awful on the web.

And this is what I think could be great for the web. Small charges for bonus features. Not a yearly fifty dollar subscription that people would only give to one website each year, but to spread it around those websites.

This is how you get money into the system and avoid teetering on a dangerous precipice of swapping limited ad dollars from company to company. But, will this ever happen? Will any company ever work out a way to make this work financially? Only time will tell.

Apple recently updated its Apple TV to much fanfare. Running on iOS, no hard drive, streaming only and very affordable. They seemed to sell well (Apple even gave figures for it, which they’ve never done for an Apple TV before).

But there was a snag. Apps. People expected Apps and Apple didn’t deliver.

This didn’t surprise me. Remember how Apple did the iPhone? Ship without apps, build the interest and market share and them make apps available when demand so dictates. The Apple TV really was a huge update and almost like a version one product. Imagine, if you will, that the Apple TV had been a huge failure and only sold 50,000. But, developers had made thousands of apps. These apps didn’t get any downloads due to small volume of devices and Apple lost its credibility with developers.

So I think Apple is taking its time, rightly waiting to see if demand asks for an app store. And, I am sure apps are coming. Certain of it. Apps on the Apple TV could make it a killer device. But, I’ve been thinking recently about how apps should work.

The first thing to consider is that this device is not an iPhone. It is not an iPad. There is no touch interface and no NUI way to interact with it. Using the Apple TV involves clicking an up and down arrow to move around a menu.

Also, there are few apps I really need on my TV. I don’t need a spreadsheet or 99% of the rest of apps in the App Store now. Also, the idea of clicking along to another menu to bring up my apps and clicking on the one I want out of my installed apps list to watch it load doesn’t seem appealing either.

So what apps do I want? Firstly, I want integration with IMDb and Wikipedia. Frequently when watching a movie or TV show I want to look up the actors or budget or something. But, the key word there is integration. I do NOT want to jump out of the film I’m watching to scroll to my apps menu, open the Wikipedia app and type in the movie title, then back out and go find my movie again. What I want is to be able to click ‘Menu’ when watching the movie and click the IMDb option. Then, knowing what movie I’m watching, the ‘app’ would show me its IMDb page and then go straight back to the movie when I want.

This isn’t an App model. This is a plugin model. And I think it wins over apps in every way.

Imagine the next type of app I’d want: content makers. For example, BBC iPlayer, ITV Player, Vimeo, Twit and everything else I’d like. Do I want to download separate apps for all these? Hell no. What I want is for Apple to provide a simple API to content makers that pulls their content right into the Apple TV. I browse some kind of content store where I add the various services I need. And, sure, they can charge a one off fee or sub fee like in the app store. But, just give me a stream on content I want to add. Not twenty different apps, all with different interfaces and different ways of doing things.

So, Apple, that’s what I want. I don’t want an app store. This is a TV. I want plugins and content.

I just hope you’re reading this.

Geez.

A.

Lou.

For a blog which started out almost exclusively about technology, I sure haven’t blogged about technology for a long time. So here goes: The iPad 2. It will be announced on Wednesday, if the hints from the invitation are anything to go by. I figured I had better write some kind of prediction post with what I think we might see. Naturally, nobody will care. But I like writing.

The first issue will be who does the presentation. I assume it will be Tim Cook, the acting CEO since Steve Jobs is on medical leave at the moment, or someone like Schiller. One thing I have seen thrown around is that the idea that it may be announced that Jobs will not be returning to the company at all at this event, or that a plan of CEO-succession may be announced. This will not happen. When Jobs does quit, Apple’s share price will have a seizure and nosedive. For this reason, any kind of announcement like this will be made after trading hours, giving the market the night to reflect on the change and time for Apple to explain why it won’t happen. The announcement won’t happen at ten o’clock in the morning at the start of a full day of trading. Moving on:

So, about the actual device. Firstly, what major changes will there be? Screen size, for example. I expect it will stay exactly the same as it is now. Apple has been more than happy to berate the 7″ devices as DOA and pointless. (I agree, too. I have used a Galaxy Tab and, for me, I found it to be portable but not at all useful.) The only reason I can see Apple making a 7″ device is if demand for them is very high and taking product sales away from the iPad, which certainly isn’t happening now. But, you never know. And, remember, just because Steve says he hates something, doesn’t mean it won’t happen – he said nobody wanted to watch video on an iPod, he said Apple would never make a phone, he said Apple would never get involved in books because people don’t read and he said they’d never make a tablet because they were so bad.

And, about the screen resolution. I think it’s perfectly good. Fantastic, even. I wrote a piece about the idea of it having a retina display before:

Then there is the issue of the screen. People are throwing around the idea of a retina display for the iPad. I think this is complete crazy talk. Let’s remember what the definition of a Retina display is: a display with which the average human eye cannot discern the individual pixels. Apple found this to be 300 PPI. Consider what this meant for the iPhone: Original iPhone: 480 x 320 = 153,600 pixels at 165 PPI iPhone 4: 960 x 640 = 614,400 pixels at 330 PPI This is a big jump and these remain very big numbers but let’s transfer this to the iPad. Giving the iPad a retina display with at least 300 PPI, the resolution would be 2560 x 1920. That may not sound a lot, but it is. That’s more than my 17 inch MacBook Pro. It’s twice as much as Dell’s highest class 24 inch monitor. We’re talking about a 10 inch iPad which would be displaying as much information as two 24 inch monitors. Imagine how much rendering this would take. There is no way that an A4 could do that. Even assuming a new processor was powerful enough for general apps, even an Xbox could barely render a fast moving game at sizes like this. You would to tie a generator to the back of the iPad to use it without a power source.

I stand by all that. I don’t think it will have a retina display. I also think people need to be more careful when they talk about things like a “slight resolution increase”. I do not think Apple will do this. The iPad is currently 1024 × 768 and increasing the resolution a bit would create a weird number of pixels. The problem is for developers. Android has this problem and Apple have slated (PTP) it before, saying that developers have to make several different versions of apps to cope with all the different possible resolutions and sizes. With the iPhone 3GS to iPhone 4, the pixels were doubled to make the retina display. This meant there was no problem for developers – Apple could easily deal with resizing things and just ask developers to make higher quality graphics whenever they could.

You can’t make 1.3 times more pixels and have it work this flawlessly. Developers would need to change things and there would be multiple inconsistencies and unpleasantness. I think there will either be a doubling of resolution (which will take us to 2048 x 1536 pixels and 264 PPI, just short of the 2560 x 1920 and 326 target for a retina display) or no change at all.

Of course, resolution doesn’t have to change for a better screen. The screen can have better contrast and colours or better viewing angles or better response to sunlight. I’m not saying it will be the exact same screen – just I don’t think a resolution change will happen.

So, what else. A camera? A cameraS? Sure, why not. While I don’t think Apple will always do things that make sense, everyone is just certain there will be two cameras. Just don’t be so certain. As I wrote before:

Apple doesn’t mind saying no to something. I can picture Steve on stage right now, saying that the iPad has a camera on the front because, ‘FaceTime is great, everyone loves FaceTime,’ and then smoothly explaining away the lack of rear camera with, ‘but, nobody wants a camera on the back, nobody wants to hold up their big iPad, nobody wants that.’

And the SD card slot? Well, I don’t think so. Again, as I wrote before:

Consider the rumour of SD slot. Right. Hmm. Well, I don’t think so. Currently, Apple sells a small piece of hardware which plugs into your 32 pin connector and acts as a SD card reader. That’s great. I can look at my photos. Yay. But thats all. It’s a reader, nothing more. If Apple puts in a SD slot, would they allow you to simply use it as storage space? I don’t think so. Apple sells three three storage sizes of iPad. There is a bigger markup on the bigger devices and I don’t think they’ll throw all that away by adding an SD slow. Reader, perhaps. But, it’s seems like too much trouble to go to to add just a reader when they can charge you an ungodly amount for an adapter.

And the boring stuff. RAM increase? Sure. New processor? Sure (I don’t it’s the A4unicorn). Storage bumps? Probably.

Then, the other news.

iOS 5: I HOPE SO. Apple usually shows it off before it ships and this seems like the ideal time. I expect one of the tent poles to be a new notifications system. And that’s really all I care about.

MobileMe for the peasants: Will it be free? Is this why Apple built their big data centre? They recently stopped selling boxed versions of MobileMe, so it’s almost certain that something will be changing. I hope it gets free.

iTunes in the clouds: Will it happen? Is this why Apple built their big data centre? I sure hope so.

“Oh, and there is one more thing:

We are making a hydrogen car! It’s called the Apple Car.

Oh, and we’ve made a super intelligent robot to clean your house and stuff!”

Man, that would be cool.

So, I just got an email from Microsoft about making apps for Windows and – in particular – Windows Phone 7 (which they’ve been paying people to develop for). They badly need apps because they think their couple of thousand looks bad up to Apple’s hundreds of thousands.

Anyway, this email contained the headline “build an app for that”.

I just thought it was worth reflecting on the difference between their’s and Apple’s app stores.

Apple’s tagline: there’s an app for that. Microsoft’s tagline: build an app for that.

I just thought it was funny and 140 characters wasn’t enough to express it.