Configuration Manager Writers - Announcements, Comments and other Stuff

This blog is used by the Configuration Manager Writing team to keep you informed about the content we are writing, the availability of new documents, updates to documents, and other news. This blog is also intended to collect feedback from you our custome

Scrub Scrub Scrub!

Scrub Scrub Scrub!

  • Comments 3
  • Likes

One truth I have learned since coming here to work is, it is easy to identify a bad user interface design, and very hard to make a good one. We spent the last few weeks scrubbing the UI text for smsv4 Beta 2. I won’t talk about what is in or out of the new UI – you’ll have to wait until Beta 2– but I want to talk about the UI scrub process.

User Assistance, aka “the doc team” is not always responsible for the UI text. It varies from product to product. In our case, we don’t officially own it, but we feel that unless the text is understandable, it’s hard for you to do your job and hard for us to write the Help, so we made it a priority to review as much as we could.

There’s a lot to think about when writing UI text. It’s just a bit intimidating to write something you know will be baked into a product and seen by thousands of people. We also have to think about how all the UI text will be translated. There are a whole slew of guidelines at Microsoft for how to write text that will localize well and we try to keep them all in mind. For example, we have to allow 30% more room than the English text takes so it can expand when translated. There are also a slew of guidelines specifically for designing UI and writing UI text.

Here’s what we did: We took screen captures of all the UI. We pasted it into Excel spreadsheets. Yeah, Excel. The Windows team found out it works really well for UI scrubs because you can keep one screen shot per tab and you have all the drawing tools and even controls if you need them. We keep one shot in the original state and then work on a copy on the same spreadsheet tab. We add new text and, in some cases, even call out where controls should be changed. We have to think about things like “wouldn’t it really be better to use a radio button instead of a check box?” And “if you click this action, does the title bar of the thing you get actually match what the action said you would get?” Then we printed it out and taped it up to the wall for a few days so we could see it all hanging together. We did about 760 screens. It was a busy week. We looked for inconsistencies across the various features.

When we’re all done, we still have to turn it over to the PM to decide what to take. Sometimes our suggestions have consequences we don’t realize. Sometimes they just have to prioritize the bugs, so everything we suggested might not make it into beta 2. Also, sometimes, our suggestions aren't much better than what we started with, usually due to what I call "scrub fatigue" - we stare at the same UI text so long that we stop really being able to see it. For example, in the SMS 2003 UI, go look at the Package properties. On the Distribution Settings tab, it says “Specify the sending priority and the preferred sender to use when sending the package to distribution points.” Pop quiz – do we ever use the sender to put packages on distribution points? Nope. But I stared at that text for years and never got it until I went into scrub mode. On the other hand, we scrubbed some of the text for the branch distribution point UI in SMSv4 beta 1 refresh and we tried very hard, but I still think what we ended up with is too confusing. 

Writing good UI text is like writing Haiku poetry. You have to grab the essence of what they need in as few words as possible. If we give you too much text on the screen, admit it, you just ignore it and go on to the next thing. But we can't be cryptic, either. Well, we try not to be cryptic. I have to admit there are a few places in beta 2 where we simply didin't have room to explain all the intricacies of selecting an option, so we had to make something that mostly worked, but might still induce you to press F1 to get the full story.

So my challenge to you is, the next time you see some bad UI, don’t just throw your hands up and pronounce it bad, try to rewrite and redesign it. It probably isn't as easy as you think. If you think it's easy, hand your results to someone else and see if they could use your UI. And hey, if you’re good at it, send us your resume. You never know when we might have an opening. ;-)

Cathy Moya, SMSUA

Comments
  • I think, one of the problem is a "Loocked GUI".

    Monad is good, but good and MODIFICATION-ABLE GUI is also good thing also.

    And what we get from MS from year to year? - Right, OVER-LOCKED GUI. Yeah, lazy MS-programmers love locked GUI because it's simple to realize. But it's hard to USE!

    Many functions live in such places that i've never seen. One function there, second (but strong related) everywhere.

    If you don't make good UI - do not it. We can it if you'll allow.

  • Hi, VladislavA,

    I'm not sure what you mean by "locked GUI". The SMSV4 SDK will provide ways to extend the UI.

  • Great post.  It's nice to hear a bit about how the product is developed and the logic behind what we see every day.  

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment