- Culture
- Design
- General
- Marketing
- Networking/Systems
- Open Source
- phpSprockets
- Productivity
- Security
- Software
- April 2011
- November 2010
- August 2010
- March 2010
- February 2010
- December 2009
- September 2009
- July 2009
- June 2009
- April 2009
- March 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- Coding Horror
- Innova @ Flickr
- Joel on Software
- Lifehacker
- phpSprockets on Google Code
- Smashing Magazine
Design Making Your Blog Suck Less
Can’t believe we missed this one: in an old post from 2005, Jeff Atwood (via Coding Horror) points us to an interesting set of the top ten blog design mistakes, which themselves come from Jakob Neilsen. Check out how many we’ve failed at, and see how many you might be missing.
Design, Software Writing meta-use cases
Update: some folks on our team let me know that the tone of this post seems very negative. That's not my intention, and this project is still going great 
Heavy handedness aside, what I'm trying to communicate is that it is important to think about everyone that needs to live with a technology solution , not just the actual users. And Agile needs to accommodate this truth. That is all.
Sometimes a project at Innova reminds me that we don't do everything particularly well. I'm always glad when we can get back to building sensible technology solutions, but it would be a mistake not to learn something from these tough experiences.
We began a new project for a major long-term client with our typical high-level system specification. Standard practice for us, this artifact of our design process describes the use cases which led to the system spec, and sketches out a preliminary interface through a rough prototype implemented as html. In our normal Agile practice, this document helps get everyone on the same page at the start of a project, and it is gradually "taken over" by a working system.
This process works, and our customer had experienced it repeatedly. The thing was, on this project, we were working with the IT group-in the past, we've always worked with business units at this client.
IT departments have different priorities than business groups. Whereas business folks care about development time (minimizing it, that is), usability, and strategic advantage, an IT group may be more focused on fitting a solution into their support organization. This means they don't want heterogeneity in technologies, and they don't want approaches that make auditors and future bosses raise their eyebrows. In short, they want to buy IBM.
Which is fine. We use stable, mature technologies and think our software is among the best designed in the industry, using high levels of code separation, DRY, and a predictable MVC design pattern. But that's not what this post is about.
This post is about the difficulty we've had communicating that our solution meets the needs of the IT group too. So, where did we go wrong? I think the answer is simple–we didn't consider the IT folks in our user-centered design documents. We forgot that they're users too. Not in the traditional sense, but in a kind of meta-sense–just like others, they have unique goals, and a design that doesn't accommodate their needs will fail. Similarly, a design that doesn't communicate its efficacy for these meta-users won't get purchased.
Here are some things we'll think about next time when considering meta-user needs:
- Is the customer comfortable with the technology approach? To be clear: Can the customer defend the technology approach to people who might criticize it?
- Does the project allow everyone to feel like a respected, useful contributor?
- Is the customer comfortable with their role in training and support?
- Does the customer feel that their resources are used as fully as possible to drive down cost and aid in knowledge transfer?
- Will the project result in the required artifacts needed for things like Sarbanes Oxley, regulatory compliance, and professional standards? Have we made life easy by packaging these up for the client properly?
- Does the project align with mission statements, charters, and organizational budgets?
- Are the stake-holders comfortable that they'll know where the project stands at all times?
- And most importantly: Did we listen carefully to everyone? Are we confident we know what each stakeholder needs to make this project a success?
Part of being a professional is aligning your actions with the customer's needs. Adopting an Agile development approach without consideration for meta-user needs is the kind of Agile development that gives the whole process a bad name. And the kind of business practice that is sure to lose contracts.
Design Expert tips for css design
Update: The pdf versions are now available. You can pick them up directly from SmashingMagazine.
Not too long ago, I saw this come across the wire: 70 Expert Ideas For Better CSS Coding I've been working with css layouts for a while now, and this is one of the most comprehensive articles that I've found on the subject. Some of these I agree with, some of which I don't. There's a ton on this list, so I'm not going to take up much time. Read the list, and finally get css working on your side. They've promised a pdf version of the article, so stay tuned.
Design, Software Initial impressions on Adobe cs3
We recently decided to invest in the upgrade to Creative Suite 3. There's been a lot of buzz about this release, and I've certainly been quite eager to see what improvements have been made. It finally arrived at our office on a Friday when I was very busy. I told Chris, one of our administrators, "I'm not even going to install this today because I know if I do I'm not going to get anything else done today." I was able to keep that promise for about 10 minutes.