- Andy L., intrepid software engineer  RSS 2.0
 Monday, July 30, 2007

A few hours of playing around with one of the earliest CTP builds of "Sparkle" (now, "Blend") got me very excited at its potential to address some familiar UI design PROCESS issues...

1)  Our client's team of marketing product managers had flown in from corporate headquarters for the annual project kickoff meeting.  After reminding us that we had to deliver in ten months in order to meet Christmas store deadlines, they proudly announced that it had been decided that EVERYTHING in this year's version of the product would be designed around the concept of a "concierge".  If the user wanted some information, they would consult the "concierge".  We said, "Fine,"  would this take the form of some kind of animated assistant, or were they envisioning a special screen that the user would navigate to in the application?  Would the feature involve recorded or synthesized speech?  Would it have an online component?"  We were told that focus groups were already hard at work, considering such questions as "If you were to invite the concierge to dinner, what would he look like?".  Four months later, a group of us flew East to participate in formal usability lab studies on the product shell, and I took aside one of the PMs, to try to pin down this still-undefined concept of "concierge".  He told me the design consultants were still busy, finalizing the product color scheme, and he was shocked when I told him they could safely delay a decision on the final RGB color values almost to the end of the project (this was MFC, so I simply #defined place-holder color codes in a header file), whereas implementing the "concierge" might require significant effort.  Six months later, we shipped a product (to good reviews) whose only reference to "Concierge" consisted of a single modal dialog.

2)  In preparation for a major revamp of the company's flagship product UI, myself and several other developers in US and German engineering departments spent several months separately implementing a number of interactive mockups using Windows Forms, while I used PhotoShop to generate over 200 additional static "screen shots" of UI alternatives that would have been too time consuming to code...

3)  I've almost always had a major role in defining the UI of the products I've worked on, writing many custom UI elements (in Windows Forms and, previously, with MFC), and working with end users or user proxies (ie: Marketing) to design the overall UI experience.  This is one of my favorite parts of the development process, and I've read most of the popular design references (Cooper, Krug, Nielsen, Spolsky, Tufte...), so I've always been surprised at the number of developers with good technical skills who seem to have no affinity for, or interest in, user interface design. In some cases, the developers simply seem unable to envision how complex and unintuitive their proposed application workflow will appear to the target (non-technical) end user.  In other cases, it's pretty clear that they consider any amount of attention to aesthetics or design to be completely irrelevant to the task of engineering an application, even to the extent of failing to size and line up controls properly, or to follow basic Windows UI design guidelines.

 

For those who have been busy with existing projects, and may still be unaware, Microsoft's Expression Blend is a UI layout tool (and much more) for WPF applications, that enables designers to generate the actual production UI for an application themselves, rather than having to settle for the developers' distortion of some carefully-rendered initial design.  Because they share the same project file format, developers can load a Blend project in Visual Studio to add business logic to the designer's work, and designers can load a Visual Studio project in Blend to professionally "style" basic control layouts stubbed out by the developers.  Blend's capabilities extend far beyond mere layout however.  Without leaving the design environment, designers can bind controls to XML data, or to class instances defined in code-behind files, or bind property values between controls.  Designers can hook up events, create and trigger animations (defined in WPF as any change in the UI over time, including the appearance and location of controls -- as opposed to the more traditional definition, which was specific to image animation), completely restyle the appearance of system controls, or implement entirely new controls.

Sound a little too good to be true?  A little skeptical that your same company management which ships products featuring artwork created by developers using MS Paint will suddenly approve funds to hire "interaction design professionals" -- and just where do you find these strange, half-programmer, half-artist, creatures anyway?  More about all that in my next post.

Monday, July 30, 2007 7:39:28 AM (Pacific Standard Time, UTC-08:00)  #    Comments [0] -
Dev. Process | Dev. Technologies | UI Design | WPF
 Thursday, July 26, 2007

I recently decided to cash in my company stock options and take the summer off to focus full-time on the latest generation of Windows development technologies (WPF/WCF/WF/LINQ/Blend etc.) and maybe pick up a few MCPD certifications, before looking for someplace new to put it all to good use.  I've actually worked with WPF/WCF and Blend off and on, beginning with early CTP builds, over the last 18 months, but now I'm ready to dig a little deeper, and the timing seemed right to get a jump on what I think will be some fundamental changes to the way companies staff and organize Windows development projects, going forward.

I started out writing applications in C for a software development shop in Japan, did alot of work in C++/MFC, and some DirectX, at two Silicon Valley startups, and have been working with C# and Windows Forms ever since the release of .Net 1.0 five years ago.  My experience has been almost exclusively with desktop and client-server applications, with web projects limited to a few experiments with personal sites (like this one).  Although I took a couple intro. to CS courses at CAL (Berkeley), my degree was actually in Asian Studies, and I learned to program "in the trenches".  I was also the .Net evangelist at my most recent company, authoring internal white papers on .Net, sending out a weekly ".Net FYI" e-mail, conducting .Net training, and sweating the truth out of job candidates who claimed to have .Net experience (You'd be amazed at the number of Silicon Valley engineers who list "three years of C#" on their resumes, who are unable to explain how to hook up a simple event handler, or identify basic terms like "reflection", "attributes" -- or "Richter" and "Löwy").

After years of preaching the need to monitor dev. community RSS feeds, and this extra time on my hands, how could I possibly NOT have a blog of my own?  So, here I am, injecting my drivel into the spew, with a site I expect will feature some combination of comments on development technologies and the trend toward more agile development practices, sprinkled with accounts of management inanity that I suspect will seem all too familiar...

Welcome.

Thursday, July 26, 2007 6:56:16 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0] -
About Me | Blogging
© Copyright 2012, MissedMemo.com
DasBlog theme 'Business' created by Christoph De Baene (delarou)