Thursday, August 28, 2008
Drupal Meetup in NYC
So, Jay let me know that there was going to be a Drupal Meetup in NYC last Wednesday and so I went along. Drupal is a web content management system that is an open source (free) solution that has an amazing user base.
Companies like Wired, and Fast Company, and sites like BobDylan.com use Drupal on their site (in fact I got to meet Steve M. who was a big contributor to the Bob Dylan site, which was very cool.) So jay and I met up in the middle of the work day in a town called Bridgewater, then we drove a little ways toward Newark and eventually hopped on a PATH train and rode into the City. Just outside the meeting was this amazing Koons sculpture. It was definitely a fun night.
Tuesday, August 26, 2008
Nested Bullets in Flash
This has, I am sure, been a point of frustration for many for a very long time. Bullets in flash. The trouble is quite simple really. You get one level of bullets, and one level only. With traditional HTML you could nest bullets just like you would in a word processor document and it would look mostly comparable. With flash, this is not the case. Take the following code for example:
<ul>
<li>Item 1:Nesting Level 1</li>
<li>Item 2: Still Level 1</li>
<ul>
<li>Item 3:Nesting Level 2</li>
<li>Item 4: Still Level 2</li>
<ul>
<li>Item 5: Now at Level 3</li>
<ul>
</ul>
</ul>
This would normally get me to three nested levels of bullets. Not so in Flash. In flash, this is how it would look:
- Item 1:Nesting Level 1
- Item 2: Still Level 1
- Item 3:Nesting Level 2
- Item 4: Still Level 2
- Item 5: Now at Level 3
The reason is also simple. Flash has no understanding of the <UL> tag. So, after years of fiddling and searching, and finding nothing, I think I have finally found the closest answer to this dilemma. Check out the following flash-specific HTML formatting:
<TextFormat blockIndent="0">
<li>Item 1:Nesting Level 1</li>
<li>Item 2: Still Level 1</li>
<TextFormat blockIndent="20">
<li>Item 3:Nesting Level 2</li>
<li>Item 4: Still Level 2</li>
<TextFormat blockIndent="40">
<li>Item 5: Now at Level 3</li>
</TextFormat>
</TextFormat>
</TextFormat>
I was working on a project where some of the text in the page needed "indenting" and I accidently forgot to close the TextFormat tag, which resulted in bullets in the remaining portion of the loaded text to indent. Eureka! A completely accidental solution!
So, this is how you translate nested bullet levels into something flash understands. Pretty straight forward. As you can see however, you have to specifically set the indentBlock to the correct precise character position for each level. It would be so cool if it were simply true that nested formatText blocks would have an accumulative effect (i.e. a formatText with an blockIndent of 20 inside another formatText with an blockIndent of 20 would, in that case, equal an spacing of 40 from the left edge), but unfortunately they do not. You are basically setting temporary indenting with respect to the extreme left edge of the textField when you use the blockIndent attribute of the formatText tag.
Sunday, August 24, 2008
New Monitor
Now, as of this weekend, my primary computer is back to three monitors! I still have to two 20 inchers... but now, in between them sits a beautiful Dell 24 inch widescreen monitor with a resolution of 1920x1200... I am in love again. Me and my monitor and getting engaged!!!
Look at that crazy thing! It is taller than the 20 inch monitors and at least a third wider. Those diagonal 4 extra inches sure do add up!
Monday, August 18, 2008
The Call - Washington, DC, Aug-16-2008 Recap Video
A day in the sun praying for Washington, DC, at The Call, on August 16, 2008. It was a beautiful day of being with friends, old and new, with the Lord and praying over the city and the country.
Cool, cool!
Saturday, August 16, 2008
Friday, August 15, 2008
Friday, August 8, 2008
Wednesday, August 6, 2008
"It works" and other Usability Measurement Myths
In my field of work I am constantly designing interfaces for human interaction (specifically on the web.) It is a requirement of my profession to shorten the time between needing an interface and finding one that is actually usable. If Usability (word #1) in its simplest form means, “Something that can be utilized by someone with reasonable intuition in determining how to interact with it,” then usability is a huge issue for people who have to design interfaces and an “interactive experience.” I would say that Usability as a requirement in that process goes without saying. Here rests part of the problem:
It works!
When discussing an interface the most common measurement I hear from folks is the ever unquantifiable “It works,” or its evil twin “It doesn’t work.” The problem is this is typically an emotive response to the aesthetic and not the usability. Let me explain, again.
Referring back to the definition of usability, when examining the intuitiveness of an interface, we should be measuring, at the simplest level, recognition time (emphasis on word #3: time.) Said another way, we should be able to ask someone “Using this interface, how do I navigate to my personal preferences?” and the time it takes for the average person to answer that question gives us a hint to the usability of that interface. Imagine if I asked the question again and the response was “It works.” What would that tell me? The fact is “It works” is a conclusion at best. At best it is a description of the interfaces functional accuracy in doing the job it was created to do. Frankly, it tells me almost nothing about whether or not the interface is intuitively usable. Which leads us to usability measurement myth number two:
Usability means it either “it works” or “it doesn’t work”
Usability is a scale, a percentage and not a Boolean (i.e. true or false.) If someone asks “Is this interface usable?” the answer is almost never “no” simply because it is the wrong question. Usability “works” in percentages. The higher the percentage the better the product. It is really that simple.
So why do people, once they see a product simply declare “It works” or “It doesn’t work” by sight alone?
Imagine you are attempting to create an interface for a fun playful toy manufacturers website. Specifically you will be building the menu system. To add a little bit of fun to the site, you create big colorful menu buttons (this would be both an issue of aesthetic as well as usability.) You decide that to stay consistent with the playful theme once they click the menu item, a little magical twinkle happens and a fairly flies around the menu for a second or two (this is not interactive but simply an issue of aesthetic.) After consulting with your client you decide that each menu item should look like a toy that corresponds with the menu items. To navigate to the menu item, you would drag the toy (the menu item) onto a graphic that looks like a old pirates chest. It seems fun and exciting! You might even decide that it does in fact successfully perform the goal of navigating to the menu items location. It definitely dovetails into the fun playful aesthetic of the site. But the average human struggling to figure out that interface might actually lower the overall usability score for the menu system. Now the aesthetic nature and the quality of usability are actually competing.
Now, just because usability and aesthetic can compete doesn’t mean it is wrong, it just means that they are not the same thing. It also demonstrates that there is not always a positive correlation between a solutions aesthetic and its usability. But again, maybe you want the user to work for it a little. That is OK as well. The key is to know that they are not the same and that both should be intentionally designed and brought into the right kind of balance.
Testing the Aesthetic:
- Review each goal.
- Examine the aesthetic and discuss how the aesthetic is meeting the needs of the goals.
- Discuss any areas of the aesthetic that are not meeting the goals.
- Create an action plan to modify the aesthetic to match the remaining goal needs.
Testing the Usability:
Usability is directly related to various level of functional goals within a solution. Usability should be reviewed within the scope of those various functional goals. That workflow looks like:
- Select a functional goal to test.
- Ask a person to attempt to perform a functional goal (you don’t tell them how, rather you tell that what the goal is and ask them to perform it within the interface.)
- Observe how they interact within the interface: record the speed of performing the task; record the patterns by which they attempt to identify the correct interface elements; record how many times they have to start over to figure it out, etc.
- Offer an opportunity to let them tell you how the interactive experience felt to them.
- (Repeat step #2 above until you have tested all of the relevant functional goals.)
In conclusion, usability and usability testing is a known science. If someone claims to be a usability expert then that means they should know how to test for usability and draw quantifiable conclusions about its quality. A usability expert is not, however, someone who knows how to bake up a really tasty interface. That might just be called a really good designer. But the best designers are folks who design with an eye to both usability as well as aesthetic and know how to draw up the right balance within a given project. If someone claims “usable design experience” that should mean that they have actually subjected their interfaces to real usability testing. Now that would be a great designer!
Saturday, August 2, 2008
McDonald daytrip to the Jersey Shore
This is a fun video I recently posted of my cousin's family and myself making a run to the Jersey Shore. We are going to need to do that again before the end of the summer, I think.