Intelligent Design : Design

Fellowship One and Microformats

FTProductDev — Fri, 30 Nov 2007 00:53:00 GMT

Quietly for the last two years we have begun integrating microformats into the portal; beginning with the first iteration of "Add Household 2.0" when we incorporated the hcard microformat into people search results and household detail view. Now you can find the hcard microformat in group view, search across groups, and in the next version of people detail. This is just the beginning.

As described on their website, "microformats are a set of simple, open data formats built upon existing and widely adopted standards." Creating a standard way of describing specific data gets everyone (consumers, developers, vendors, browsers, plug-in creators) on the same page. An example of this is Michael Kaply's excellent Operator add-on for Firefox. If you're not using Firefox to run Fellowship One, you will be now (and shame on you if you're not already). Here is an example of Operator in action on people search results.

Here we have the results of a name search for all individuals whose name contains "McFedries":

Nothing special here, three individuals with address, phone, and email. But. Hold on a second, if you have Operator installed you'll see something special *is* going on here.

Here is a screen shot of Operator:

Operator has found three microformats for both "Addresses" and "Contacts".

Let's take a look at "Addresses".

Operator has found the addresses within my search results and provided me a way to map those addresses via Google or Yahoo! maps.

Now, let's take a look at the "Contacts" menu.

Just like "Addresses" Operator has found each individual in the search results. Choosing "Export Contact" will export the contact to vcard format and import into my contact management system (Address Book, Entourage, Outlook, Windows Mail) of choice. You could also import all individuals from the search results by choosing "Export All".

Operator is a great add-on for Firefox and a great companion for Fellowship One. Even Bill Gates agrees, "We need microformats".

- matt

SXSW Day 3 - I know kung fu

nfloyd — Thu, 15 Mar 2007 18:27:00 GMT

Ok, so I don't know kungf u but I was able to make it to the Ajax Kung Fu Meets Accessibility Feng Shui panel. The first half of the presentation was pretty interesting. Jeremy Keith used some screen captures from the Matrix to help illustrate his points or at least make his presentation look cool. He talked about how there is a fine line when using cool new mechanisms like AJAX - a line that is often crossed making good apps go bad.

Next up was Gamer's Games: Microcontent and User Creation. My interest in this panel came from the unbelievable growth of user-generated content and how it has taken the web community by storm. What I didn't expect was the excellent discussion that we got into about the various types of content generated from users that exist outside of the normal cloud of graphics, movies, blogs, etc... things like personalities and relationships. It gave me a lot to think about regarding building community in the apps we write... good stuff.

After lunch we peddled over to Bullet Tooth Web Design: Plan Your Web Site like Pulling off a Robbery. This was more entertainment than application, and I figured that wearing black ski masks in our daily scrum probably would not go over well with management. They highlighted the "quick and dirty" on how to approach web projects...

The highlight of the day was the Yahoo! BarTab after party. Not just because there was tons of swag, or free everything, or even because we got to hear The Little Ones (they definitely were a highlight though). We had a unique opportunity to interrupt Robert Hoekman Jr. and his wife having a conversation. Originally we thought that we missed an opportunity to talk to him during his "Why we should ignore users" panel - but we successfully backed him into a corner and fired away. It was an awesome experience. It was nice to talk to someone who truly loved doing what they do.

SXSW Day 2 - Why we should ignore our users... Wha?

nfloyd — Wed, 14 Mar 2007 18:49:00 GMT

After dragging ourselves out of the hotel room (it seems that Austin has some sort of mystical property that makes you super-tired in the morning. Combine that with the time zone change = 2 grumpy coders. 2 grumpy coders + Starbucks in the convention center = :) ).

After getting some caffeine we hit the doors running and made it to the best panel of the day: Why We Should Ignore Users. Cutting through all of the analogies and acronyms the session mostly focused on ACD, err I mean Activity-Centered Design and User-Centered Design. Robert Hoekman Jr., arguably one of the best designers in the industry, provided some strong points for going with ACD. My personal opinions on it is that ACD is the way to go, it gives the team a rallying point and a solid filter to avoid creep and other project killers. A side note I definitely recommend reading Hoekman's book: Designing the Obvious - you will not be disappointed.

Shortly after I hit an unexpected jewel of a panel: Serious Games: Can Learning Be Hard Fun? Serious games can be defined as any game that provides any type of educational benefit beyond the basic entertainment value. The little goodie that came from this panel wasn't seeing them play cool games, or talk about the business side of educational games, but rather hearing them share their point of views on what happens when you involve users and the community in the software development process. The real focus of the panel ended up being how to engage your users and keep them engaged.

We then hit: ValleySpeak for the Rest of Us: Developing Apps Outside InternetVille. Pretty good stuff - the panel consisted of Dan Cederholm and Brian Oberkirch. No real hot points - it seemed that they were just trying to point out the fact that really good software can be developed outside of Silicon Valley. Right now one place comes to mind: Irving, Texas.

Uniting the Holy Trinity of Web Design capped off our day. They began talking about the 3 aspects of web design -- Data (HTML), Style (CSS), and Behavior (JavaScript) -- but later jumped into team interaction and development / design as they have experienced it...

All and all a pretty good day... more to come

Old Dog, New App

nfloyd — Thu, 15 Feb 2007 19:08:00 GMT

Last night I finished my taxes. Though it was no small feat it seemed almost pleasurable - before you call the IRS / local asylums (one in the same) let me explain:

A coworker turned me on to an awesome book by Robert Hoekman, Jr named designing the obvious. Hoekman talks about practical approaches to designing web applications - nothing revolutionary, right? That's what I thought...

In the past I have always bought the tax software, downloaded it, installed it, updated it, used it (rather misused it), updated it again, submitted my taxes, then uninstalled it - never to be used again. I do this because, just as Hoekman explains, "Typically, users latch on to the first [software] tool they find that they can tolerate, and they stick to it."

Yes, I lost count of how many times the application crashed or had to be updated, and it wasn't the fastest or easiest to use, and yes I often felt like the software was telling me "you're not good enough to use me, do you even know what a 1040x is, ummm you don't need to use that field but I have displayed it there to mislead you muahaha...". But I used it none the less, not willing to try the web version.

From "designing the obvious": "When an application is designed badly, it tells you at every opportunity just how bad it is. But when it's good, you usually can't explain why it's good. You can't put your finger on it, but you know it when you see it."

I used the web version of the software this year. Initially I was insulted, barking out things like, "What!? You can't even search on which form your using", "Where are the long explanations of what fields 1-200 mean", or "Where are the gratuitous fields that are intended to mislead and distract". As I used the app I began to get it - this old dog was eating his own food.

They designed the online tax program based on the activity that needed to be preformed (Activity-Centered Design - Designing Web Applications for Use) and dropped the over abundance of "enhancements" and so called "features" its client based brother has.

After being humbled by great software design and confidently addressing the burning hot coals of Tax Season I felt good, empowered almost. "Software shouldn't force users to understand how it works so they can learn to do things with it." - designing the obvious

That's what makes good software, that's what makes an obvious design, that's what empowers users to get the job done.

Asp.Net vs. Standards

mvasquez — Fri, 02 Feb 2007 23:29:00 GMT

A few months back I converted our site template from a table-based layout to a standards based design. This was not a trivial task, in essence I "touched" every page in our app, which is more than 300 pages. Recently we released major pieces of functionality, both using standards based html and heavy client-side functionality (ajax via prototype, effects/drag drop via scriptaculous). For the entirety of the project I was in a constant struggle with asp.net and it's blatant disregard for supporting standards based design and HTML standards in general. Listed below are the issues that drove me to the edge of insanity, almost to the point of shunning off asp.net forever.

INamingContainer

I understand the need to uniquely identify objects in the control tree. But why does that id have to be persisted to the client? How are you suppose to get a reference to an element in css or javascript if you can't rely on the id? I've got an idea, stop trying to hold my hand and let me be responsible for uniquely identifying my controls. This leads to abusing the class attribute and using it where it simply should not be needed.

One form per page with runat="server"

I've been told that this has since been addressed in 2.0. In 1.1 this is unacceptable, for instance, in our site template we have a drop down within our sub navigation (don't ask me why it is in the navigation) that contains all ministries a user has rights to. This drop down should be contained within it's own form, along with a form containing all controls within the main content section. but because a) System.Web.UI.WebControls.DropDownLists must be contained within a form with runat="server" and B) only one form with runat="server" is allowed on the page; I now have to encapsulate the entire sub navigation and content in a single form. There-by sacrificing good design.

Controls render horrendous HTML

So I've just added a System.Web.UI.WebControls.DataGrid and I've set the DisplayHeader to true and HeaderText to "Name". Ok, let's see here, we have a grid that should be displayed as a table (check). We have a header for that grid/table, so that should be a table header, th tag, (che....oh wait). Where is the th tag? There are too many of these instances to list each one.

System.Web.UI.WebControls.Label renders as a span tag

Did anyone on the asp.net team even look at the HTML specification?

No support for OPTGROUP element

Seriously? I mean, come on, DID ANYONE EVEN LOOK AT THE HTML SPECIFICATION?

Quirksmode is default for new aspx pages

If you truly support web standards how can you default a document to Quirksmode.

No easy way to get HTML from a server-side control

A significant advantage of ajax is not having to render the entire page, especially if sections of the page may or may not be used. On the server an ajax request is not handled any differently than clicking a button or link. There is a significant advantage in being able to request pieces of HTML from the server and respond with that HTML to be rendered on the client (AHAH). but because asp.net controls must a) be apart of a form with runat="server" and b) cannot be rendered before the form is rendered, this is impossible. Besides creating a user control and then loading that control at runtime there is no way to get HTML from an aspx page. Well, no way that I could come up with.

System.Web.UI.WebControls.DropDownList must be contained within a form with runat="server"

Why?

Did I miss something? I'm not too terribly familiar with the machine.config or the web.config, maybe I forgot to include <standards-mode enabled="true" />? Microsoft's marketing machine can preach all they want about standards support (why do I still have to use the Holly Hack in IE7, wasn't this bug fixed? ), but marketing will only go so far. People will tell me that concessions have to be made in order to support the designer and being able to drag and drop a control from the toolbox. But you know what, I don't care, if your dragging and dropping controls from the toolbox then you need to find another profession. Creating web applications is not for you.

Does anyone else struggle with these issues?

Time is a constraint we should embrace

mvasquez — Tue, 03 Oct 2006 16:09:00 GMT

In a perfect world developers would have an infinite amount of time to create the most elegant, perfect, scalable and enterprise-quality architecture/solution ever. This, my friend, would rival the airplane. Heck, it might even rival God's greatest creation. Well, sorry to be the bearer of bad news: this is not a perfect world. Time, in anything we do in life (development included), will always be a constraint. You will never have enough time.

Time is a good constraint.

When we embrace time as a constraint, we take the first step of being real with ourselves. If we truly don't have enough time to implement what has been asked for, we have to be open about it. We have to be real about deadlines. We have to get real about project management and cut scope, change the design, or reprioritize requirements. Or we have to get more time.

If the functionality is important enough, they (customers, bosses, etc.) will find the time.

This is when we can throw all excuses out the window and begin thinking creatively in order to work within our constraints. As developers, this is where we live. Time is a constraint that we should embrace as an opportunity to be creative. So, the next time you hack together a piece of functionality, don't use time as an excuse. Be real with yourself: what truly caused you to make that decision?