Bare Naked App

Amigo is a tricky beast as we’re not only accepting payments, we’re also paying people. Here’s how it works:

1. Person A pays Carson Systems (Amigo) with their credit/debit card. We use Secure Trading’s XPay module to do this.
2. Carson Systems generates an invoice (marked paid) and emails it to Person A
3. The money goes into Carson Systems’ bank account
4. Carson Systems uses the PayPal API to pay Person B

The last step is the really tricky one. Watch the video to see how we solved it!

RSS readers, view the video here.

We wrote the text for the website a while ago and passed it over to Jason, who has since produced some very stylish designs for the site’s homepage. However, there has been some debate on how to present the strapline for the app (or in simple terms, the sentence that explains what the app does).

Ideally, your strap would state exactly what your app does in simple language, in one neat sentence (max 5- 6 words). However, things are not always that simple. In our case things were complicated by the fact that we have two types of user. If we aimed the strapline at one type of user we would effectively alienate the other by completely ignoring their needs. It took us a while to get our heads around this one.

When we wrote the text in Word a couple of weeks ago we thought we had it pinned down. We would write a vague (catch-all) strap line in a kind of “connect, share, be friends” kind of way (once again Amigo is not social software it’s just an example). And then we planned to use a longer sentence to really nail what Amigo does, aimed at both sets of users. It seemed to work - on paper.

When Jason sent through the design (see example number one) we knew it wasn’t right. It was too long-winded and it took an age to actually ‘get’ what the software was about. It was all wrong.

Roll in example number two (second down from top). Here we tried to drill down to the very basics of what the long sentence was trying to say. We split it into two sections (one for each type of user) and put a bullet point infront of each. The style we used was: “User number one: this is why Amigo is great for you” then “User number two: this is why Amigo is great for you”.

Nope! This was still not working because lower down the page Jason had created some neat little icons to represent each type of user and your eye automatically floated down to read the text associated with which user you were. The bulleted list was now superfluous and actually confused the eye when looking for data.

So we ended up with option number three (third down). We deleted all extraneous waffle and let the icons draw the users in to their particular area, where they would be told, succinctly and quickly what Amigo can do for them. It worked.

The whole process of deciding this one very small (but very important) part of the site took us the best part of week.

And by the way these screenshots are not Jason’s final designs. I have replaced the original text with dummy text so that I could post about it here. The real versions are slightly neater!

Apparently there’s interest about the environments we’re all working in. First the eye-candy, these three picture’s are what I consider the main parts of my working environment.

1. The "geek" section of my book shelf (and, yes, there is also a non-geek section - it’s good to have a balance!). It’s a good reference, some good reads, some half read (awaiting my time), and it’s always growing. Books from Algorithms to [dare I admit it] Visual Basic with much in between (and, yes, alphabetically ordered).
2. Servers and other hardware, well, the current ones.. there’s been a few over the years! I’ll run through them quickly:
   • Mac Mini (only really use for Safari testing)
   • SMC router
   • DEC programmable switch (thanks Gary - one day I’ll get round to setting this up)
   • APC Powerstack UPS - that needs replacing.. I can’t have both servers on and running through it at the same time!
   • IBM xSeries 330 (hopefully the future dev-server for my own app!) running Gentoo linux
   • Custom built 4u server / desktop, also running Gentoo with KDE as a desktop, RAID, SATA, aeroplane engine.. no, that’s just the fans! This is where I do most of my browser testing, Internet Explorer (ies4linux), Opera, Konqueror, etc.
   • (in lower picture) IBM t30 laptop which has both Windows and Ubuntu Linux using GNOME as a desktop. This is where I do all my communications (email, skype, sip, im) from, keeping them on a separate machine limits the distraction.
   • (in lower picture) Motorola E680 - a linux phone (also waiting for my time!), for daily usage I’ve got a Motorola v3.
3. Desk space, this is a temporary setup all due to change (rack enclosure, Herman Miller Aeron chair, etc) in 2 months or so, but the main part of all this is my keyboard, a Goldtouch Adjustable keyboard, RSI is not something to ignore and this keyboard really helps!

When working I spend most of my time in bash and vim, followed by Thunderbird and Akregator. There’s always music playing - can’t work without music, top of the list to get me coding is at the moment are:

• Raga Against The Machine’s Renegades
• Ali Farka Toure & Toumani Diabate’s In the Heart of the Moon
• Johnny Cash’s At Folsom Prison

(how depressing, none of them play anymore!).. I’d be interested in what gets other coders coding, music? coffee? a good environment? On that note, time I started coding..

I’ve been putting this off because it’s one of those really boring paper work things (yuck). Once I finally did it though, it proved to be very easy (took me about one hour). Here’s the steps I took:

1. Searched the trademark database for similar items (we’re good, phew!)
2. Downloaded the TM3 form
3. Printed out our logo and taped it to the correct place
4. Filled out the form
5. Chose category 9 and 42 as they applied to Amigo
6. Signed it
7. Wrote a cheque for £250
8. Sent it off!

Hooray! Now we just hold our breath and hope we get it. If we don’t it means we have to start over with the logo and branding. Not good considering we’re launching soon.

Jason wanted to use Futura Medium as the typeface for headers on Amigo. The only way to do this (to my knowledge) is sIFR, a clever technique with Flash that allows you to use any typeface you want, regardless of whether or not the user has it installed.

There’s one major drawback to sIFR though: if you increase your font size, it doesn’t dynamically scale. It will only rescale the browser text size if you reload the page. I think that this is a pretty big usability problem.

So in the end, we decided to go with bold Arial. Obviously not quite as fun, but definitely more user friendly.

Sheesh, after what seemed like two years, our server is finally ready. It’s so exciting to see the app actually working in the dev environment.

What we learned from all this is that it’s wonderful to have a developer who understands Linux boxes and can run their own server. We survived on Dave’s server up until now and it really saved the project from falling behind!

Jason has been working hard on the interface designs. He’s pretty much finished most of the sections of the app. Here’s a sneaky preview of how they’re looking. They’re small so you can’t see the words but you get the general idea. Jason has coupled the logo with a smokey blue background and used a tab device to enable users to get around the interface. We really love the colours he’s used (not too serious but not too kiddy either). He’s also used a nice mix of serif and sans serif fonts that we think really make it that little bit different. Each screen is super simple with everything you need to operate the app in one tidy place. The Q&As are located down the lefthand side and will (hopefully) help us to answer users’ questions as they go.

Jason is still working on the interface designs so this is very much a work in progress. Some tweaking will occur as we go through each slide to test its usability. But initially we’re really happy with what we have so far.

Just a quick note to say that the deadlines have changed slightly again. This is more because things are just taking longer than we thought they would (designs going back and forth, fundamental questions from our developer that need more than a yes or no answer etc) rather than us falling behind because of external forces.

The new deadlines are:

• Start website design = 19th May
• Finish website design = 26th May
• Website XHTML started = 29th May
• Website XHTML done = 2nd June
• App coded = 16th June
• Launch = 7th July

This means that the launch has been pushed back to July 7 (previously 22nd June). This is not ideal, and to be honest we are hoping that we won’t need that long. But we can only wait and see. We’re more or less on track though, which is encouraging! Whatever you do, don’t skimp on your contingency time - you’ll need every last second of it.

When we built DropSend, we learned that good project management can be the key between going way over schedule or delivering on time (and budget).

When it comes to project management, here’s the important stuff:

1. Milestones
2. Project assets like logos, graphics, wireframes, etc
3. Messages
4. To-dos

In order to manage all this, we swear by Basecamp, a great tool from 37signals. There’s a free version if you only want to manage one project, and then it moves up to $12/mo. (We’re on the $24/mo plan, so we can manage 15 different projects at a time.)

The reason why Basecamp is integral to the process of building this web app is because we have to manage three freelance teams (Jason - Designer, Dave - Developer, BitPusher - Server Team). Doing it all over email just gets too confusing. It’s great to know everything is in one place.

One of my favourite parts of Basecamp is the Milestones area. It really helps me understand where we’re at with the project. The screenshot above shows all our completed milestones. Late Milestones are red, and upcoming ones are yellow. Seeing a bunch of green ones (completed) really makes you feel great and top of things! (And of course, seeing red ones makes you panic!)

One thing we’ve learned is to reply to messages quickly. If your designer or your developer asks you a question (usually over Basecamp) then reply straight away. They may be working on the project in the evenings, or at the weekends (as they are freelance there’s no reason why they should work on it 9 - 5) so this may mean checking e-mail at the weekends. Whatever you do, to keep the work flowing, answering queries fast is the key.

Jason finished the UI for Amigo late last week, so once I got to a natural break within the code I was currently doing I decided it was time to start on the XHTML/CSS (jumping in and out of code too often isn’t productive, wait for a nautral break!) - I’m sure Ryan, Gill, and Jason can’t wait to see something that both works and looks the part, I know I can’t!

While the XHTML/CSS isn’t completed quite yet, it’s been more interesting then other projects I’ve worked on: this has been the first project where I’ve built the wireframes in XHTML before any design has been done. So rather then coding the XHTML from a blank slate I’ve been refactoring (as such), and so far I’ve noticed a few things:

• Early on we had something to look at. Yes it was rough, but it was in a browser - where it would end up, for everyone working on the project to see.
• Refactoring XHTML is very quick - while some pages needed more editing then others they were all done quickly.
• Refactoring CSS isn’t - removing redundant styles after the changes to the XHTML, checking all the browsers etc. isn’t as quick as refactoring XHTML!
• Any interaction questions you had about the UI will become much clearer once a version of it is working with the back end of the application.

If your in a similar position any time soon, and haven’t tried "XHTML wireframing", I’d recommend it, even if just to see if it works for you and/or your team. Personally I’ve not 100% made my mind up, I’d like to try it again on another project before I do, but so far it seems mainly positive.