Building English360
For over just a year now, I've been working on an e-learning application for English360. You may have heard of them as the site made it into Stylegala having been designed by Cameron Moll.
I had originally intended to only work on the project for a few months to work on designing the application. However, once we got to the development stage, I decided to stay on board to develop the application as well. The project has now turned into an ongoing, long term client with updates and new features going in on a weekly basis.
Working with a client who "gets it"
The guy behind English360 is Cleve Miller, who has been involved in English language training for almost 30 years, has a pretty good head on his shoulders. Throughout this project, one of the best things I've enjoyed is being heard and allowing to be heavily involved in shaping how this application should come together.
Having this much say in a project was rare when I worked in an agency, but has been commonplace since going freelance. Some of this comes from where my involvement lies in the entire development process. As a freelancer, I'm in it right from the beginning and have the opportunity to say something before any decisions have been made. When working in an agency, decisions had already been made by the time it got to me.
What's interesting in retrospect is how passionate we were about our point of views without being mean. Also interesting: using analogies can lead to very confusing discussions and are usually too disconnected to the argument at hand to be overly useful. (As evidenced by one conversation talking about shopping malls and whether going through certain doors would confuse shoppers.)
Designing the Application
Designing the application was a fairly lengthy process — much longer than I've done on any project previously. We went through a one week brainstorming session along with Carson McComas, who was involved in the project even before I came on board. During this session, we began to map out all the features that we felt should be in here. It was also important to determine some long term goals to understand how the core of the application would ultimately be built.
From there, we went through putting together wireframes for each of the major screens. Some of the minor screens didn't get designed until implemented in the application. While some feel that wireframing is too restrictive once you get into the design stage, I've been happy with the success I've had so with it so far. Alternatively, you could look into something like Page Description Diagrams.
After getting the wireframes done, I put together the designs for the application. Each screen got mapped out in Fireworks before touching a single line of code.
Prototyping
At this stage, I'd normally just jump into the actual application development but Cleve was insistent on putting together an HTML prototype of the application. This was a good thing as it forced as to truly look at how the application might behave and allowed us to really simplify a number of things within the application. (To say that 37signals got quoted a few times, for better or for worse, is an understatement.)
A CMS at heart
From a technical perspective, the application is really a content management system for e-learning, allowing users to create different types of content including tools like multiple choice questions, drag-and-drop exercises, and a calendar. To pull off a flexible system, I decided to use a technique I had discussed way back when I was going to build a generic CMS: using XML to store unstructured data.
Adam Thody put together most of this portion of the application and I have to say, it turned out really well. This approach, tied in with CakePHP, has been really flexible. It'll make adding new item types much simpler moving forward.
Each item in the database has default metadata that it stores in the item table with its individualized data in XML also stored in the database. To help make search work effectively, each item can decide what data should be searchable and is included in a search field that is indexed. The data is a little de-normalized but performance-wise, this should hold up well in the long run.
The rest of the application came together fairly smoothly and while CakePHP didn't have all the features I needed, it was easy enough to extend it when I needed to.
Challenges
The largest challenge was simply getting the work done. It certainly took longer than expected. I had brought Adam Thody in to try and get the project out faster but with his existing clients and my need to bring on additional clients to manage cashflow, I suddenly found myself in over my head and no further ahead.
In the new year, as the project came to a close, Adam left to focus on his own clients again and I refused any new clients. I put my nose to the grindstone wrapping up testing, debugging, and tweaking the design. What was left was a cool application with a lot of flexibility.
Worth it?
There are certainly things I would have done differently but ultimately, I'm happy with the end result and with ongoing changes, it'll be interesting to see things evolve. Often times, I'll build something, give it off to a client and never see it again. This time around, I'll have a hand in continuing to shape things.
Conversation
The logo looks like the Cingular logo .
@Johan: similar remarks were made when the site originally launched. I think they're substantially different in implementation but do have a similar style.
Does anyone else see the irony in a site promoting English training opening with the phrase "English360 leverages the web".
http://incisive.nu/articles/31/HitListLeverage
David, I wrote the site copy you refer to. Our audience is mostly Latin American corporate professionals who don’t speak English fluently, and the site copy was written for that audience. It’s a challenge because the word selection for that audience is often different than when writing for a native English speaking audience. For example, I choose words of Latin origin (“obtainâ€) because they are often very similar in Spanish (“obtenerâ€), whereas your good ole Germanic-origin words (“getâ€) aren’t as familiar. While I would select “get†if I were writing for you, for our specific audience my intention is that they understand with as little effort as possible.
Now this isn’t the case with “leverageâ€, but for better or for worse, “leverage†is a word our audience sees every day in the .ppt decks they are subjected to from corporate HQ, and it connotes something good and powerful for our audience. I like the word because of how it conveys the idea of using a tool that multiplies the energy employed, which the word “uses†doesn’t do. But in the face of the withering criticism of the page you linked to, I may well need to re-think that…I sure didn’t realize that “leverage†elicits that level of scorn these days and that’s certainly something our students should know about certain audiences!
Anyway thanks for the feedback – it was useful.
If leverage is a word that you audience is "subjected to" (especially in the form of PPT presentations from corporate HQ), then they probably realize what a meaningless, fatuous example of PR/marketing-speak it is. They're less likely to take you seriously because of it.
On the other hand, if your audience is the group of corporate nincompoops largely responsible for perpetuating this sort of drivel, or the marketers who are beholden to them, then you've done a great job.
The site looks really well done. How did the design work split between yourself and Mr Moll ?
Could you go into some more detail about the searchable xml item data? Are you only able to specify one element to search on, or are you able to specify many? Just wondering how you translated this to the db tables - do you have one table per item type ? Questions questions :)
@Aaron: to be clear, I worked on the design and development of the e-learning app and Cameron Moll was not involved in that. He had designed the web site but that was about two years ago now. So, despite working for the same client, Cameron and I haven't worked together (maybe some day).
re: search xml item data: the way I accomplished this was to store the searchable data in its own field without any XML. In other words, just raw text. I did this for two reasons.
By storing the data this way, I've only got one table that stores all my item data. That's it. Each different item type has it's own XML format but I no longer have to worry about storing data in separate tables and having to join them together. It's turned out really well.
Thanks,
sounds like a nice way of doing it for that sort of information. Any performance concerns, or will the volume of data mean its a non issue ?