Your own Mulit-touch Surface Prototypeboard-thingy.

Today it hit me that a co-worker and I have been using a mini-whiteboard in a way that could easily be used as a way to prototype Surface style applications or ideas you may have.

IMG_0232 Let me explain, there is a partition between me and my co-worker which used to be a locker of some sort (no idea actually). It’s pretty high in terms of size and given its between the co-worker and I it’s kind of suddenly become our meet/greet tabletop.

On top of this partition is a mini-whiteboard that we have (approx 50cm wide and 50cm high) and it’s fast become our “hey got an idea for the UI” or “hey need some help with OOP composition” meeting point. We typically sketch out our problem/idea and then proceed to – yes you heard it first – communicate with one another on what’s possible etc.

We often call it the poor-mans Surface table as a joke, but in reality if i were to work on a Surface / iPad etc style application it’s this little whiteboard I’d love to have in the room. As I’m then able to sketch out the ideas and walk others through it via old skool pen + paper mode but at the same time can allow quicker iterations then “can you hand me that eraser” or “let me get another sheet of paper” ..

Anyway, thought I’d share this little eco-friendly prototyping tool for all to think about.

IMG_0233

Related Posts:

Silverlight Installation / Preloader Experience – BarnesStyle.

When I was in the Silverlight Product team, I had many visions of where I wanted to take the product beyond where some of my co-team mates were comfortable with (slow painful incremental growth in terms of change).

One of the main focal areas I wanted to fix, was the overall Installation and Preloading Experiences for Silverlight. In that, i think it’s essentially the like the IRAQ war of software (i.e. meaning, its so far embedded now that fixing it is going to take generations of change).

Here is how I’d love to see it change course.

Change the way Silverlight Boostraps.

If you new-up a project within VisualStudio or Expression Blend, you will effectively get an automated boostrapped solution, meaning inside your main Silverlight project via App.xaml.cs for example, you should see something like this:



        private void Application_Startup(object sender, StartupEventArgs e)
        {
            this.RootVisual = new MainPage();
        }	

What effectively is happening here is that Application Class is the default root for Silverlight and when you inject “MainPage()” into the RootVisual its pretty much the same as if you went:


	UserControl MyUserControl = new UserControl();
	MyUserControl.Content = new MainPage();

What I would love to see firstly is a separate Project called “BootStrapper” created as part of the new-up Project template – that or it prompts you to create one much like it does at the moment with ASP.NET Website (More on that below)

The point is, it draws the developers around the worlds attention to the fact that the Spinning Balls are really bad idea to hand out to public facing websites.

Why are they bad you may ask?

It has to do with the way end users approach your experience and assuming they have Silverlight in place, it’s important that you give the end users some clues as to what they are loading and what is the likely time or more to the point is this going to take forever?

Impatience is a virtue all users have so its going to be very hit or miss depending on what the context of your application expected usage is and lastly the end users broadband connection and tolerance for plug-in experiences in general (I counted like 5 variables of failure that can occur per user when I did some research on this back at Microsoft).

The rotating balls don’t offer much value, there’s nothing to keep you entertained or interested in the experience other than balls rotating and some % of where I’m at.

Soliciting the end users.

Just like a hooker, your job is to entice the person before you to take faith in the hopeful reality that this will be an experience to remember (ok that analogy just took a nose dive in very bad way). Your job is to firstly convince the end user to install Silverlight should it not be in place and secondly and just as importantly your job is to convince the end user that sticking around is also equally important SHOULD they have the installation in place of Silverlight.

You first need to have inside your webpage “You don’t have Silverlight, go get it and here’s what you will get in return” vs the dreaded “Get Silverlight” medallion.

To illustrate this importance; when I was at Microsoft we noticed on Microsoft properties an increase in installation of Silverlight when we actively went out of our way to solicit end users to Install vs the default “Get Silverlight” medallion – information is power, users want power just as much as the next person, power of choice.

Once they jump through that hurdle, you need to again keep their attention on you and try and convince them to avoid the temptation of alt-tabing and twittering etc while they wait – think of all end users as a 3 year old child’s attention span and you will be better positioned for success here.

You need to create a preloading experience that is as helpful and joyful as the intended experience you’ve just spent $thousands of dollars creating (why drop the ball at the last yard! – for you NFL fans)

In this you create something that is part of the theme or take a page out of MAXIS Games where you insert random crap that’s quite funny – example:

“…Initializing launch codes for anti-nuclear attack”

”…Growing Llamas feet so it can walk…”

”…Handing a Monkey a nail gun for entertainment value..”

Keep them informed but not too informed as you want to balance out keeping them informed whilst not making them aware of “time” as that is the enemy, “time”. I’ve even lied once due to a latency hit that I couldn’t avoid, so I put in the initializing splash screen “Checking Security Credentials”  (Given I found end users were more likely to wait for a serious thing like Security to validate vs.. staring at rotating balls of stupidity).

That all aside, this is the “Why” both Preloading/Splash Screens and Install Templates are critical for SIlverlight’s future success as this in turn is what end users judge the technology on (Do i need to bring up the “Skip Intro” debacle of the early 2000’s where Flash Intros were all the rage and bad bad experiences with Flash occurred as a result).

First: Install Templates.

Imagine if you will, you new-up a Silverlight Project. You’re asked obviously what type of project you require and then in the next step it prompts you with the below:

image

You then choose your Install Template and it can be both an Online or Local template (more on Silverlight Marketplace potential later). Once you select the template, this then will take a vanilla themed experience and injects in into your MySilverlightProject.BooStrapper project. You as a developer and/or designer can then focus on swapping out these assets and messaging to suite your intended experience context for your brand etc (much like the larger brands have done with Silverlight today – e.g. MSNBC etc).

Second: Preloaders/Splash Screens.

Same approach as the Install Templates, except it automatically attaches the intended original Silverlight project you wanted as being the “First” to load (but with enough breadcrumbs in code that you can also swap this out should you choose to).

image

Once you have gone through these three templates, your solution should have 3 projects in place.

  • Project1 – MyProject.Silverlight.BootStrapper

    This project’s job is to handle the preloading of Project2, as in order to preload you first have to have a project that is very small in size for Silverlight to load, then once it’s loaded, Silverlight can then automatically bring down the .XAP file (secondary but main project) in a more controlled and aesthetically pleasing manner.

  • Project2 – MyProject.Silverlight

    This is the project you originally intended to use, exact same structure(s) as you have today in Silverlight.

  • Project3 – MyProject.Silverlight.WebThis is the project which is in place today in terms of automatically generating the said ASP.NET / HTML project code you need to test with. Except, it also injects a bunch of files/scripts which handle the “Does the end user have Silverlight?” which then based on a Boolean result reacts and produces a prompt that goes beyond the “Get Silverlight” medallion.

The Marketplace.

Ok, you can technically write a VS Template or WPF/WinForms app today do the above without having to bug Microsoft (i’ve started and stopped 3 times – stopping only due to boredom or busy). Why this needs to come from Microsoft is simply put – Marketplace.

We should have a concept where we can buy/sell Themes, Behaviors, Preloaders and Install Templates etc from one another whether it be by cash, XBOX Live Points or whatever currency you want to barter with. Point is, we should foster more of an exchange based community that is more consolidated and branded under a single point of entry for both Silverlight and Expression (say NO to Expression and Silverlight/WPF segregation– designer / developers need to cross-pollinate).

I’d love to see a similar concept as preloaders.net and scalenine.com for the Silverlight community only less fragmented and one that has a much smoother tooling integration experience (I’ll come back and work at Microsoft if need be to make this happen).

Summary.

I’d like to see us as a community leap frog the Flash community in terms of handling these two experiences. As the below illustration highlights the fatigue gates associated with any plug-in experience.

image

Why leap frog Flash? it’s nothing to do with their community it has to do with “learning from their mistakes” as at the moment Flash folks have figured this out and have a bunch of strategies (whilst fragmented) in place to fix this broken situation. We on the other hand are like the retarded step-child twice removed when it comes to picking up on this, and it erks…ERKS..me (for I am ERKED) to see the rotating splash balls and Get Silverlight Medallion – which incidentally were just a placeholder animations and images that someone forgot to come back and replace.

We fix this we drive Silverlight installation experiences up by minimum 20% per month, I guarantee you that much. As it will lesson majority friction associated with Silverlight and drive a much more deeper awareness of the product amongst consumers who aren’t reading the blogsphere for “What is Silverlight?”

The “What Is Silverlight” is still a question being asked a lot today. It’s one thing to answer that, but it’s another to attach friction to and users experience of the said product once they’ve found a satisfactory answer to that question with bad preloading/installation experiences – OUTSIDE – of Silverlight today.

This is both a Microsoft and Community problem that needs immediate resolution.

Call to Action: Contact Microsoft and hammer away at this issue, get more of a community groundswell behind it so that we can all move forward. I remember inside the team, community reaction was one thing we often would use to trigger emails with one another on why change is important.

Vote here so this can be escalated to the Silverlight Feature planning team! – : http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/632735-silverlight-installation-and-preloader-experience-

Related Posts:

UX Tip: Just because you can count change, doesn’t make you a mathematician

I was watching a MIX2010 video from Microsoft’s head UX guru, Bill Buxton on how specifically developers and designers engage with one another. There was a throw away line he put out there, which was stated in reference to developers whom often think that because they have a bit of design muscle deep down that they too can contribute to the design discussion –

Just because you can count the change in your pocket, doesn’t mean you’re now a mathematician.

I laughed when I heard this as yes, design is an art (who knew) and often at times we take it for granted a lot more than we probably care to admit out loud.

For me personally, given I’ve visited countless developers in a variety of scenarios in the Microsoft space, one constant theme I see continues to emerge, developer art.  This consistent pattern is the exact fit for the above analogy.

Allow me to explain further..

Developer Art

image

Developer art is the composition of a interactive solution that almost looks good enough to ship, but when you start to tease away at the various threads (i.e. DataGrids) you begin to see that there isn’t a lot of structured thought put into place behind the “Why” the screen is structured the way it is. In that, they often tell a story as to why it’s important to cram as many UI elements onto a screen making full use of all the pixels you are given and then some. It has certain hints of developer based design and structure but it comes across very adhoc and chaotic in thought.

“Oh yeah, I’ll add that button in later..”

I admire their intent (truly), but sadly this is really just re-echoing bad habits into a new medium and all we’ve really done going forward is polished the cumbersome UX and it’s attached pixels with a brighter gloss – the problem continues to live on though, and user’s are expected to jump through hoops due to poor software development planning and useless deadlines that in reality are more than likely going to increase the problem rather than decrease it.

Note: Most devs i’ve engaged with this, are aware of this as well, and are openly keen to get this fixed (very encouraging days ahead).

That being said, developer art tends to lead into Pixel Cramming

Pixel Cramming

image

Having a large screen is tempting to do a lot with, but in the end we must remember an important fundamental about humans, in that we like to chunk information into pieces that make sense to us. We listen to a story and isolate important pieces, in that we tend to skim read large documents and isolate important facts / figures. We often hear a story and isolate key pieces of information and bank that into our working and/or short-term memory.

Chunking is a clue to how your end users approach things in general, yet with developer art UI, it tends to be blatantly ignored. The reason being is, most of the time developers want to take a large resolution of pixels and fit as much data and finite amount at that, onto the one screen – because users like to analyse all of this data is usually the response I often hear.

I could inject countless research papers here on how humans + density = cognitive overload and the chances of recall and/or visual encoding are diminished as you layer more and more amounts of data. I don’t though as depending on how you deliver that message can lead to an emotive discussion focused around the words “I think”, less “I know” (which is really the base primitive used to instantiate an argument randomly.

Instead I come at it from another direction, that is asking the developer(s) to consider layering complexity.

Layer in Complexity.

image

I often tell developers to start easy and then layer in density or complexity (as you learn more about your end users expected habits or paths of access).

I do this for a number of reasons.

Firstly it’s a sneaky trick I play on you, as it forces you to think about the big picture first from an end users perspective, whilst it then removes you from that pesky habit of getting bogged down in the finite details (engineers play chess with UI, they are always trying to guess 3 moves ahead).

Once you structure the surface of your UI in a way that mimics the way humans process information, you just may stand a great chance at producing some UI that doesn’t feel like a page out of the classified section.

Secondly, another reason as to why I ask you to layer in complexity/density is that it can help safeguard you from creating lots of virtual problems that probably don’t need solving. What I mean is that approx 80% of your end users are likely to only use 20% of your features, which in turn means that if you were to ship V1 as a very basic piece of software without the cascading density of UI you would in turn raise questions within your user base that are mostly likely going to yield you a lot of “I know” to questions that are probably coming up with “I think” today.

(Behind the scenes you are effectively doing an on the fly qualitative analysis on your said upcoming software’s development approach).

What If I were to come into your developer enclosure tomorrow, walk up to your feature task board and steal 30% of the features away from your product randomly. How would your end users react? I know how you’d react, but really, how would you’re end users react. Would they even notice it’s missing and if they did notice it was missing what story would they in turn tell you about why it’s important. Once they do tell you this information, and I only agree to give you half of the features back, how would you weight the importance against what you already have today done or still on the board.

My point, you do this anyway, you often start out with a healthy amount of feature requests, but through the inertia of development these features get squashed, contorted and at times glossed over in the development process. It’s a really negative impact on what started out with so much positivity.

Bottom line is this.

image

Engage a UX Professional as well as a UI Professional, as in the end they think about these various points allot (at times both from different angles), and typically see the world for the chaos that it is and less inclined to care about you the developer (It’s not you, it’s not me either, it’s them, ya know, the end users). If you don’t already, do some persona development around your product and it’s important to do this. If you have done this, then grab some wall space and scrap book various clues about the end user for all to see. Remind yourself daily who it is your developing for and why. Ask yourself “Which person’s life am I going to ignite with this feature being done perfectly, done in an ad hoc fashion and/or not done at all”. You should have an answer to this with a degree of confidence that should be shared by all.

Does this mean all design is hands off to developers?

Yes and no, if you aren’t passionate about the concept of what design is, you really need to step back and let someone who is genuinely curious about solving problems for end users through interface design and less about shipping schedules or how brilliantly they orchestrated their MVVM architecture. As the ironic thing about development patterns is you’re building software to make life easier for developers to be apart of? funny, why can’t you do the same for the end users?

I’m not an expert, far from it, I’m just experimenting out loud with all of this, but the more I data I gather, the more I start to see how all these puzzles fit and all to often, developers are trying to be too many roles at once and well, humans are never really good at multi-threading – hence we chunk.

Related Posts: