Archive for the ‘Software’ Category

My favorite thing about software is when it teaches me something about myself that I didn’t know. That something doesn’t need to be important, it just needs to be something. I’m a huge fan of twitter so I was pretty excited when I came across this twitter mashup. It uses Yahoo Pipes (to parse data client side) and Google Charts (to present data) to show you a scatter chart of when you typically tweet and bar charts of your tweets by month, day of week and hour.

It’s a really interesting representation of my twitter activity and technologically it is a sweet use of both Yahoo and Google tools. So what did those charts teach me? Simple: I tweet most between 8 and 10PM on Wednesday and Thursday. I find that interesting. Also, Saturday around 2PM seems to be popular for whatever reason.

I write all this for one reason. The next app that you build, think about this. Think about how you can use the data that your users are entering to teach them something about themselves. It can be something silly, like when they tweet the most, or something more profound that they would have never noticed without your help. Every time someone clicks or types in your app, it’s a chance for you to collect data and teach the user something about themselves or teach you something about how they are using your app. Don’t just build something to collect data. Build something that learns what your users are doing and adds value to their lives.

Some Related Links

• Google Web History - what months, days and such you search the most on, what terms you search for the most, suggests searches you might be interested in based on your habits
• Google Reader Trends - shows you which days you read feeds on, which feeds post the most items, which feeds you read the most or the least, etc.
• Flickr Stats - stats on your photos views, but also on which photos you’ve tagged, put in sets, etc.
• Last.fm - shows you what music you listen to and suggests stuff you might like

You may or may not know that I’ve been building a pretty sweet (in my opinion) website management system at Notre Dame. Every content management system of any sort on the web always starts with a text field for a title and a text area for content. Knowing this, that’s how Conductor started. Each page was made up of at least a title and some content.

The Trend

Now, with 13 sites live and another 16 in development, I am seeing a trend. Most pages on the web are more than just a title and some content. Thankfully, when originally developing Conductor, I tweaked some ideas that I liked from other systems and created page parts. Basically, we can put a page part in a template and a new tab will appear in the page editing area. The picture below has a main content area and three page parts (info, thumbnail and url).

The Problem

Nothing seems wrong with that idea, right? It allows us to store content in smaller chunks which gives developers more control over markup, which in turn gives designers more control over layout. Wrong. Exhibit #1: the edit window for a page using a faculty template on the law school website.

Below is an example page rendered in the template above.

We wanted to show things like biography, courses, and contact information in unique ways but not force content owners to mark things up uniquely. Because I assumed that all pages will be made up of huge content regions and not tiny pieces of data, the only way we could do that is by creating a page part for each item we wanted to store separately. This, as you can see in the screenshot above, caused a very tab happy interface. While this works, I believe it creates a sub par experience for the content owner (who does all of the updates). One reason I believe that is now the content owner has an entire text area, to fill in something as small as a website url, which could be better represented by a small text field.

The Solution

All of the above has led me to an idea. It might be something that sounds good as an idea but in reality would be awkward. It might also not be my original idea, as someone else could have used it somewhere in the same fashion I speak of, unbeknownst to me, but here it goes. All you need is a way to store data and a way to present data. Also, those two things are completely intertwined. How you want to display data affects how you want to store it. The more control you need when displaying data means the more separated the data needs to be stored.

Each piece of content that makes up a website needs two templates: one that determines how it is stored and the other how it is displayed. There could also be a third template that is how it behaves but I’ll leave that out for now. I think the ideal website management system has almost a form builder interface for developers to define what they need stored. From there, the developer should also be able to create the xhtml or xml or json templates that determine how the data will be consumed. The final piece of administration would be an area where content owners can fill in those created forms with glorious content.

The Use Case

Here is an example use case. Content owner wants to show courses on their website. Developer creates new content template called ‘Course’. They define the storage half of the template to be name and number as text fields, professor and semester as selects (from comma separated list of options), summary as a text area and order the fields how they should be presented to content owner. At this point, the content owner can begin entering name, number, professor, semester and summary for all their courses, while developer starts creating the other half of the template, which is how it should be viewed by site visitors. Developer dumps in xhtml, css, and javascript to view all the courses styled up to meet a designer’s every whim.

You might be thinking, uh, duh, this is what happens on every web application. Someone needs something stored, so you create your model and your controller and your views and you are good to go. You’re right, but that stuff always happens at the programmer level and requires a programmer to do it. What I’m thinking about would be at the software level and could be done by anyone with front end web development skills (xhtml, css and javascript).

The Conclusion

Once this beast was created, a front end web developer could build dynamic websites very easily tailored to a content owners needs and the administration of the website could be left in the hands of the content owners. The bad news is that I would have to start from scratch to build a pure version of what I just explained. The good news is I can get close to the same result using what I’ve already built in Conductor (more on this at a later date).

I’ve been working on a really cool new feature for our website management system, Conductor. Initially, I drafted up the database tables I was going to need. I poured over them, making sure that I wasn’t forgetting anything. The whiteboard with the database tables is pictured below. Once I was satisfied with how I was going to store the data, I dove into the code and started implementing the whiteboard drawing I had created.

Bad Start

About three or four hours in, I realized that things weren’t going the way I wanted and that it was going to take a lot longer than expected to implement. The solution that I had come up with felt complex and was going to require a big rewrite to our theme system. Anytime something feels complex, I go back to the whiteboard because it usually means I haven’t fully thought it through. A bit frustrated, I went back to the whiteboard. This time instead of starting with how I would store the data, I focused on how I wanted to present the data (the interface that the end user would see). Again, you can see my scratching below.

Good Start

As I framed in the interface on the board, the problem started to seem simple and I came up with a new way of doing it that would require no alteration to our theme system or any other existing part of Conductor. Also, this new way makes more sense.

Conclusion

So what am I trying to get at? I think this has taught me the difference between good software and bad software. Bad software starts with the developer thinking how they are going to store the data and technically make it work. Good software starts with the end user. It firsts figures out what will be the easiest way for the user to learn and use the feature and then figures out technically how to do it. I don’t think this is a revelation or that I’ve never built anything in this manner. I am sure, though, that I wasn’t as aware of this before when building applications.

Don’t start technical and force implementation. Start with the interface and let things come naturally.