Designing for a Touch World

In this series I plan to explore some of the issues of Touch UI’s, this is as much a documentation of my learning experiences as it is anything else. The content will be based primarily on observation and conjecture so while I find the information helpful it is up to you to verify its suitability to your situation.

If you have contradictory viewpoints, additional ideas/information, or real ‘study results’ please chime in in the user content section – the more we talk about these things the better our UI’s will get.

Ok, on to the first installment…

Smart phone touch

When you think of modern smartphones you probably expect a Touch Screen. Seems that touch would be an easy medium to design for, after all your user can see and interact directly with the content.

As it turns out this isn’t actually the case…

Fingers are big, fat, clumsy pointing devices and the point of contact between your finger and the screen is not at all easy to determine. Worse, once you touch the screen you completely obscure whatever it was you were trying to interact with. People tend to judder and bounce (especially on the train or tram) and it is very easy to end up with accidental touches. Add this to the seriously limited screen space, potential for unwanted palm contact, and the extremely limited range motion available (try using a mobile device one handed) and it begins to seem that creating a good experience is almost impossible.

Thankfully this extreme is also not the case.

I think mostly because they are obscuring the screen (or more importantly desperately trying not to obscure the screen) most people seem to touch the screen slightly below their point of attention. Android devices seem to struggle a lot with taking this into account, Apple’s iPhone on the other hand excels at it. At times the iPhone seems almost psychic in its ability to correctly identify the part you were trying to touch. So this variation is something to take into account when developing UI’s on these mobile platforms… on Android aim to have a bigger touch target and require less precision.

Side Note: In some ways it is a shame that all the excitement over capacitative touch screens and finger input has completely sidelined the stylus… sure the stylus isn’t ideal for everything but for some tasks it beats the hell out of fingers and has the added benefit of mostly leaving the screen visible. I for one am hoping to see the stylus make a return at some point in the near future.

The availability of touch.

There are only a limited number of touch gestures available. More with multiple fingers obviously but the more fingers your are trying to interpret the great the chance you will get incorrect inputs.

What are the types of touch input you can reasonably expect from a user using one finger and holding the phone in their hand at the same time?

  • Tap

    This one is pretty obvious to most users, touch and release without movement (or at least very little movement – no one can hold perfectly still). Contact times vary depending on the user – some people press firmly and hope for some feedback, others stab at it quickly and with force hoping for a better result, some touch it as if it is fragile. Your UI probably shouldn’t discriminate between these actions.

  • Swipe

    Touch and drag the finger across the screen in a more or less constant line. Also pretty much an expectation.

    The easiest swipes are in order: sweep an approx 1/4 arc (for right-handers from mid-right to top-left or vice-versa), top-to-bottom, left-to-right, right-to-left, bottom-to-top.

    Other swipes such as on the diagonal are possible but markedly harder to perform.

  • Drag

    Touch and drag the finger across the screen in a variable line… potentially with many changes in direction. Obviousness depends on the context but with appropriate cues most people will get it.

  • Flick

    The ‘flick’ is also fairly intuitive, however it seems that when a user is about to flick the screen they subtly change their grip on the device leading to a difference between the Flick and the Swipe.

    Ease of flicks in order: top-to-bottom, bottom-to-top, left-to-right, right-to-left (harder). Other flicks are possible but non-obvious and require much more dexterity and conscious attention.

  • Long Press

    Less obvious but once learned becomes second nature. The press, hold, release without moving the finger to get a long press. Expect to have to explain to the users how this one works if you are overloading the Tap gesture on the same ui element.

  • Circulate

    If you figure that most people holding a device one handed will be interacting with it using their thumb another relatively easy gesture is to touch and circulate your finger as if rotating around a clock face. This one doesn’t see much use and is less obvious than the above. For right-handers anti-clockwise motion is marginally easier. Expect to have to explain to the users how this one works.

  • Others

    You might imagine other things such as double-tap but due to the screen obscuring issue getting in the way of user feedback such gestures are less reliable/obvious. You can of course use them, but think long and hard first.

Next time I’ll look at multi-touch gestures, and then follow up with some information about using these gestures and what the user means when they touch your screen.

Computing is personal… touch even more so 🙂

You must be logged in to post a comment.

community content (1 approved comment so far)
Click to expand

Sharply Handling Errors
Click to expand

As we all know C# provides for relatively elegant handling of errors with its try{} catch{} finally {} construct.

There are a couple of gotchas such as ThreadExceptions which bypass this stack and can only be caught at application level but for the most part it works ok.

However, there is one bug bear that drives me nuts, nuts enough that I have to write about it.

Catching multiple exception types

To catch multiple types of exception coming out of a block of code we are forced to write multiple catch() blocks, one for each type of exception.

If it makes sense from an application perspective to treat these differently then no problem, however, if we want to catch a lot of different exception types and perform some relatively simple logic on them (such as logging and re-throwing) it can be really irritating (not to mention buggy and hard to read) to maintain a long list of blocks.

Sure, we can factor out our exception handling into its own method, but this breaks the readability of the code and still requires a long list of “catch(…) {HandleError();}” statements which is a pain.

Wouldn’t it be nice if instead we could use syntax more like the using statement?

catch(ArgumentException)
catch(OutOfMemoryException)
catch(UnathorisedAccessException)
catch(CustomException)
{
    // handle error here
}

Now I realise that this has a problem, kind of a big one – what about the error object?

Well, that brings me first to another point… why do we always have to name our error object ex?

catch(Exception ex){}

Since we can only ever have a single error object inside a given catch block couldn’t we do something more like the set{} accessors? I.e. automatically name the object “value”?

e.g.

catch(ArgumentException)
{
    var msg = value.Message;
    // handle error here
}

Well, yes and no. I mean it looks nice and I have no doubt it would function… but unfortunately we can nest try-catch blocks within each other… so we would get name clashes (which instance of “value” are we talking about…).

Should we ever nest try-catch blocks within a catch block? I can’t say I ever have… I would argue that if error handling gets that complex it should be moved out to its own method. Unfortunately someone somewhere has probably done this so introducing this automated error handling would be a breaking change 🙁

Assuming such a change was possible then we could handle the multiple exception types realtively nicely by simply having the type of ‘value’ be the base type Exception. Why is this valid? Because by catching multiple exception types in a single handler we have already declared that we do not have any interest in their specific contents… so being able to get the basic data should be more than enough.

catch(ArgumentException)
catch(OutOfMemoryException)
catch(UnathorisedAccessException)
catch(CustomException)
{
    log(value.Message);
    Application.Exit();
}

Sadly this is all a pipe dream, but I’d love to hear your thoughts on it… especially if you are a frequent user of nested catch blocks.

Update

I thought about this some more and came up with another syntax which might work and which perhaps could be done without making it a breaking change:

catch(ArgumentException,
     OutOfMemoryException,
     UnathorisedAccessException,
     CustomException) as ex
{
    log(ex.Message);
    Application.Exit();
}

Since we currently can’t use commas in the catch() part by introducing a comma we notate instantly that we are using the new syntax, we can list as many types as needed with minimal effort, and we can re-use (read abuse) the ‘as’ keyword to name the resulting object.

In this way we can have everything we want without breaking existing code… always a bonus 🙂

Connect

Turns out I’m not the only user with this desire… I found this Microsoft Connect sugestion on the same topic 🙂

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

Basic XAML Part 4 (Generics)
Click to expand

By default XAML only supports generics in the definition of types (or in other words the root element). It does this by using more x: magic. The x: TypeArguments attribute lets the type derive from a generic class.

Lets take a simple base class with a single Generic type parameter T.

[System.Windows.Markup.ContentProperty("PropertyOne")]
public class SimpleBase<T>
{
    public object PropertyOne { get; set; }
    public T PropertyTwo { get; set; }
}

Then we can pretty easily create a XAML derivation of it so:

<custom:SimpleBase x:Class="TestType" x:TypeArguments="sys:String"
                   xmlns:sys="clr-namespace:System;assembly=mscorlib"
                    xmlns:custom="clr-namespace:ConsoleApplication1;assembly="
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
</custom:SimpleBase>

Apart from the odd way of specifying it (and honestly how else would we do it in xml?) this works.

However; all is not quite as it seems…

If you now try and set any kind of property on the object or any kind of nested content the compiler accept it but the runtime will blow up in your face with one of a bewildering array of possible error messages, most of which are as helpful as salt water on a boat.

Why? Turns out the reason is pretty obvious once you know. When the XAML is compiled it generates a new type, when we try to set the properties using InitialiseComponent() the runtime basically uses reflection under the covers, however it cannot correctly determine the class name because it seems to ignore the Generic Type Argument. I almost consider this a bug in the XAML system.

Anyway, as normal the most important thing is to know how to get around the problem. And the trick appears to be to only set Proeprties from XAML that are declared on a base class of our generic type, muchly irritating because in this way we loose half the power of generics but (as we will see in another post) still more useful than nothing.

[System.Windows.Markup.ContentProperty("PropertyOne")]
public class BasicBase
{
    public object PropertyOne { get; set; }
    public string PropertyTwo { get; set; }
}

public class SimpleBase<T> : BasicBase
{
}

I think therefore that it is fair to class the Generics support of XAML is pretty limited!

Side Note: Multiple type parameters can be specified in a comma seperated list.

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

Basic Xaml Part 3 (its own Assembly)
Click to expand

So my last XAML basics post ran aground when I couldn’t get custom objects to accept pure textual content. Since that time I’m glad to say a concerted documentation reading effort unearthed a little gem: Pure textual content can only be used when the enclosing type is defined in a separate Assembly.

Why is that? Haven’t got the foggiest idea but suffice it to say it probably won’t be a significant issue in normal use since the only reason to use Xaml is likely to be working with some kind of framework (WPF, WCF, etc) that will come wrapped in its own Assembly anyhow.

So having made the tweak to put my SimpleBase class in a separate VS Project (==Assembly) and licked the text issue I want to press on probing the rest of the xaml-space.

Event Handlers

First up on the hit list were EventHandler wiring, e.g.

<custom:SimpleBase x:Class="TestType" 
                    xmlns:custom="clr-namespace:ConsoleApplication1;assembly="
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                   OnClick="HelpHandler">
</custom:SimpleBase>

after some Reflection I can report that it works just like you would expect – it adds a delegate to the HelpHandler method to the SimpleBases OnClick event when you call the InitialiseComponent method of the SimpleBase instance. Nothing fancy going on here – nice 🙂

x:Name

Then we get on to a bit of cleverness, introducing variables/properties using x:Name. This is kind of strange because it gives a completely different meaning to an attribute than normal – normal attributes in xaml are (best I can tell) evaluated during the InitialiseComponent call. x:Name however actually adds new members to the type being defined (further conflating the two concepts).

What type of member does it add? Actually it seems to Infer the type it needs to be from the type of the object being named, thus <Button x:Name=”Quest”/> will create an internal member variable of Type Button called Quest. The value of this variable will still only be set during the call to InitialiseComponent.

OK, accepted, but what happens if we name a button inside a grid inside a xaml element? To find out I created some simple types and did some more reflecting.

<custom:SimpleBase x:Class="TestType"
                    xmlns:custom="clr-namespace:ConsoleApplication1;assembly="
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <custom:SimpleTypeOne x:Name="SimpleVarOne">
        <custom:SimpleTypeTwo x:Name="SimpleVarTwo">
        </custom:SimpleTypeTwo>
    </custom:SimpleTypeOne>
</custom:SimpleBase>

The result is that both SimpleVarOne and SimpleVarTwo are declared as internal member variables of the TestType class. Or in other words nesting of the XAML appears to have no impact on the declaration of the members. In many respects I’m not sure what else it could mean but it is certainly interesting and worth keeping in mind.

Summing up

I have one more thing to investigate in this line for which you should tune back in next time, however XAML is now more of an open book to me and hopefully you. To summarise:

Xaml is a conflation of Type Derivation and Property Assignment.

The Root Element specifies the Base Type and via the x:Class attribute the name of the New Type.

Any element can be named with the x:Name attribute and this has the effect of creating an internal member variable with the given name and the Type of the element on which it is applied.

The Type is compiled at compile time, but the properties are not set until an instance is a) created, and b) initialised with a call to InitialiseComponent().

The Type created by the xaml is automatically marked as Partial, this is what allows us to have the code-behind file. The code behind is nothing more than another partial class with the same name.

If you look at the auto-generated xaml code behind file you will find the call to InitialiseComponent slipped into the constructor where it can perform its magic on type instantiation.

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

Basic XAML Part 2
Click to expand

What does it mean then to declare nested xaml elements inside our simple class then?

e.g.

<custom :SimpleBase x:Class="TestType"
                    xmlns:custom="clr-namespace:ConsoleApplication1;assembly="
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
Test
</custom>

Well, if you try it you will find this isn’t possible. And indeed I also can’t figure out what it might mean. And yet if you open any book on XAML you will find things like <button>Click Me</button>. Hmm.

The answer lies in the definition of the base type (in our case SimpleBase).

In order to be able to assign direct content such as this we must declare a property on the base type and add a [System.Windows.Markup.ContentProperty(“…”)] attribute to it where the … is replaced with the name of the property that should take the content.

    [System.Windows.Markup.ContentProperty("PropertyOne")]
    public class SimpleBase
    {
        public string PropertyOne { get; set; }
        public string PropertyTwo { get; set; }
    }

Now in xaml we can assign the value PropertyOne using the following syntax:

<custom :SimpleBase x:Class="TestType"
                    xmlns:custom="clr-namespace:ConsoleApplication1;assembly="
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:sys="clr-namespace:System;assembly=mscorlib">
    <sys :String>Test</sys>
</custom>

Interestingly it still isn’t possible to directly enter the string ‘Test’, only to assign a sys:String object containing Test. Putting Test directly in the xml leads to a compile error.

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

Learning Polish
Click to expand

So, my girlfriend is taking me to meet her Polish parents in Poland… and me without a word of Polish, cripes!

Thankfully we were able to sit together and take a few important words apart to work out what they sound like in English (roughly).

English Sounds Like Written As
Yes Tack Tak
No Nyeh Nie
Please Proshem [Prosheown] Proszę
Thank You Djin koojem Dzię kuję
Good Morning Djin dobri Dzien Dobryń
Good afternoon Djin dobri Dzien Dobryń
Good Evening Dobri vierchor Dobry weczór
Good Night Dobraanots Dobranoc
Hello (friendly) Tjesht Cześć
Goodbye Dovidzenya Dowidzenia

And the basic numbers…

English Sounds Like Written As
One Yeden Jeden
Two Dvah Dwa
Three Tschi Trzy
Four TshTeri Cztery
Five Pjeowntch Pięć
Six Shestj Sześć
Seven Shjedem Siedem
Eight Osiem Oshjem
Nine Djevjeownch Dziewięć
Ten Djesjeownch Dziesięć

I’ll be back with a few more things later… happy Polish 🙂

P.s. If I got any of these wrong is undoubtadly my fault.

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

[Short Story] Headless Pride
Click to expand

The train rushed to a halt beside her, the 8:41 to somewhere exciting no doubt, but for her the daily chore of getting to work. She scrambled aboard like the hoards of faceless others around her. Always busy, always full. She never even noticed when the train pulled out, mired as she was in her own misery.

The train rocked, the train rolled, the intercity rattled and screached as it hurtled down the tracks.

She sat in second class where the seats were packed in tight and her knees sweated, wrapped as they were around the knees of the big sweaty guy sitting accross from her. Horrid. But what choice? First class passengers would be reclining in their seats and being served champaign and canapes right about now, but in this world of crisis only a very select few could afford the luxury. Clickity clack, clickity clack, the scenary rushed by; a blur of colour, a riot of flickering shapes, a smouldering ruin here and there.

To pass the time she chatted to her current squeeze on the Berry, a ball and chain that shackled her to her corporate life more securely than any fence or wall ever could. No matter where she went, no matter who she saw or what she was doing she was on call 24 hours 7 days a week. And for what? A measly living allowance barely more than the state handouts given to those too lazy to work for a living. Daily now she wondered if maybe they had the right of it… but her pride was strong and she was too stubborn to just give up and abandon her dreams.

So here she was hurtling towards another metropolis of the corporate machine. Her goal today was to convince some sharply dressed, arogant, full of it sales guy that the product he was so successfully selling didn’t exist, had never existed, and frankly never would exist. It fucked with her head that in this twisted world if the sales drone sold the cure for aging it was the techs who couldn’t produce it in time that would loose their jobs. The bloody sales guy would undoubtadly get a few mill in bonuses and move on to another similar job in another company where he knew equally little about their products and would care even less.

Inside she was furious and shaking, but on the outside she was calm and alert, projecting competence and carisma. It was this self mastery of expression that allowed her to succeed at a job she hated, to get on in a world stacked heavily against her. But it didn’t bring her happiness, didn’t get her that rich husband she dreamed of, or even enough dough to buy a damn car.

The train was slowing now, breaking hard, really damn hard. She slid forward on the seat, pressing almost intimately into big sweaty dude. What the hell? This never happened. She scrunched into the guy as the train breaked even harder, the breaks screaming, a high pitched screach that had half the passengers screaming.

Bump, bump, bump the carriage kilted to the right and shuddered to a halt. Stationary and in silence. All the passengers looked at each other, looked around the carriage, peered out the window. What the hell? The train was not stopped in the usual spot and there were people running all over the platform like headless chickens. It was only a matter of moments before the rumours started. What had happened? The train had come off the rails. The train had hit someone. The train had broken down. It was a bomb. A terrorist. A collision. No one really knew but with every passing moment the stories got wilder, the terror building among the passengers.

The Berry in her hand went dead. For the first time in living memory she was trapped in a box with no information sources, no access to the net, nothing to do but sit and wonder what had happened.

Being who she was she declined to speculate, allowing the swirling rumours to pass right by her and instead concentrate on observing. Watching both her fellow passengers and the people rushing about on the station.

That this was no ordinary occurence was quickly clear… the majority of people on the platforms were running away from the train, some of them were crying, some screaming, most just looked numb. All of them seemed to be content to be herded like sheep down into the lower level passages. The station personnel, and yes, she even saw a few police officers here and there, all of them looked bewildered and out of control.

Nonetheles a sort of order was slowly forming, with police moving towards the train and pretty much everyone else moving in the other direction. Not looking good. The guys in orange appeared to be errecting some sort of baricade between the train and any possible vantage point from outside the station. Something bad was going to happen, she was almost sure of it. Some of the other passengers had noticed too… she could feel the tension rising, any moment now it was going to erupt into panic.

Just as she thought it was about to go bang the doors hissed open and a uniformed officer stuck his head in.

In clipped millitary tones he announced “Everyone needs to leave the train in an orderly fashion. Look only forward. Do not look around. Do not look back. Once off the train move as quickly as possible to the exits.”. He didn’t exactly shout but his words filled the train, they brooked no argument and carried a weight of authority she could only dream of being able to achieve.

Almost as if they were swimming in treacle everyone looked around. Bewildered they began to gather their stuff. One by one they made their way from their seats, down the central isle, and out past the officer. As every person passed him he repeated the instruction. Like sheep they did exactly what they were told.

Most people were off now and she was begining to look suspicious by not moving so she picked up her shoulder bag and clutch purse and headed to the door. Again the officer repeated the instruction. But she was not cowed by authority and determined to understand what was going on looked around her as she stepped off the train.

It was gruesomely clear what had happened, bodies and body parts lay twisted and smeared between the train and the platform. More bodies were under the train. Steel girders and glass was littered about half way along. She was stunned. So many dead, so much blood. She glanced down to see her carriage was sitting on top of a large lump of concrete and one solitary headless man. He lay there twisted and still. So still. Unlike the scene further up he didn’t appear to be bleeding but somehow that only made it more chilling.

There was no time to see more, herded as she was by the furious guide. He nudged her, pushed her, shoved her even to the stairs. Giving a final heave he forced her off the platform and into the thronging crowd all confused and lost. Travelers in the middle of the journey, travelers unable to start the journey, gawkers, and beggers, all thrown together in the tight underpass. Coralled and marshaled but directionless and without information.

Somehow she found her way to the outside world. But what now? She was miles from her destination and hours from home with limited funds and a ‘net blackout.

Dazed she stumbled onto a footpath and wandered in approximately the direction of her original destination. Her mind was working like mud. Every thought was followed by a flash of that man. Headless. Still. Dead.

It could have been her. How could she live with that? Why go on? What was the point if everything could be snuffed out in an instant. Had he left loved ones? Had he died alone. Was he a happy man or miserable? Did he deserve what was coming to him or was it a cruel mistake?

Why?

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

Most basic XAML
Click to expand

As part of gaining a deeper understanding of WPF I felt it was important to gain a deeper understanding of how XAML works and what it actually means. Therefore I will attempt to use XAML independantly of WPF…

Naturally my first question was “What is the simplest XAML file I can conceive of?”.

What I came up with was this:

<sys:Object xmlns:sys="clr-namespace:System;assembly=mscorlib">
</sys:Object>

If you create a new Console Application and add a code file called “Test.xaml” then enter the above code it will build. Yipee.

But what does it mean?

I was assuming it creates a new type extending Object, unfortunately since I couldn’t specify a type name I had no way to test that assumption. So from here I wanted to extend my question to include “and I can reflect on”.

A bit more playing landed me this:

<sys:Object x:Class="TestType"
            xmlns:sys="clr-namespace:System;assembly=mscorlib"
            xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</sys:Object>

This allows me to create a new type called TestType that extends Object. How do I know this? I can access it from my Main function by calling:

TestType t = new TestType();

Great… so I fire up reflector expecting to find a decompilation giving me:

using System;

namespace ConsoleApplication1
{
    public class TestType : Object
    {
    }
}

But, no, it is a load more complex than that. What I actually get to see is:

[GeneratedCode("PresentationBuildTasks", "4.0.0.0")]
public class TestType : IComponentConnector
{
    // Fields
    private bool _contentLoaded;

    // Methods
    [DebuggerNonUserCode]
    public void InitializeComponent()
    {
        if (!this._contentLoaded)
        {
            this._contentLoaded = true;
            Uri resourceLocator = new Uri("/ConsoleApplication1;component/basictest.xaml",
 UriKind.Relative);
            Application.LoadComponent(this, resourceLocator);
        }
    }

    [EditorBrowsable(EditorBrowsableState.Never), DebuggerNonUserCode]
    void IComponentConnector.Connect(int connectionId, object target)
    {
        this._contentLoaded = true;
    }
}

Holy batman and robin. That was not quite what I expected, although the good news is it does indeed create a new type that derives from Object it also implements IComponentConnector.

However, when you stop and think a little it appears that XAML is in fact the conflation of 2 quite different concepts. The first is class definition (what we expected) and the second is Property Assignment (the extra stuff).

I’m assuming therefore that calling InitializeComponent will traverse through the inner XAML setting all the properties of the object.

Unfortunately using Object as the root does not let me test this, so I quickly whip up a simple base class:

using System;

namespace ConsoleApplication1
{
    public class SimpleBase
    {
        public string PropertyOne { get; set; }
        public string PropertyTwo { get; set; }
    }
}

And then modify my XAML to:

<custom:SimpleBase x:Class="TestType"
                    xmlns:custom="clr-namespace:ConsoleApplication1;assembly="
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</custom:SimpleBase>

NOTE: Notice the use of “;assembly=” at the end of the namespace definition, this is the most conformant way of specifying “look in the current assembly”. It also has the added advantage of making it easy to re-direct later if you refactor the type into a new assembly.

OK, so with that done I can again compile my program and I expect it to be just creating a new instance of TestType (derived from SimpleBase) but not yet setting any properties.

Score one for careful thinking… it does exactly that.

Next up I add a call to on my object t.

TestType t = new TestType();
t.InitialiseComponent();

I would expect this to change nothing since I don’t actually specify any of the properties in XAML.

And indeed it doesn’t, however it does change the hidden field “_contentLoaded” to true.

So for the next test the obvious step is to specify some values for the properties and see if they get set a] before the call to InitialiseComponent or b] after (or c] never…).

<custom:SimpleBase x:Class="TestType"
                    xmlns:custom="clr-namespace:ConsoleApplication1;assembly="
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
            PropertyOne="Hello"
            PropertyTwo="World"
>
</custom:SimpleBase>

I can tell you now that the expected happens and the values are set after the call to initialise component.

So the first step of understanding XAML is completed.

What is XAML?
It is a conflation of Type Derivation and Property Setting.

Urg, I hate conflations. But OK, it is what it is and that is the future of programming according to MS.

Join me next time to dig deeper into XAML and how to use it.

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

Conflate with care
Click to expand

One of the worst user interface design errors is the conflation of two unrelated concerns. Unfortunately it is depressingly common.

Take for example Back and Up. Frequently these are conflated into a single button leading to unexpected user behaviour. This is currently bugging me on my Android phone… I use an app that opens a screen that then sends me to my e-mail, I press ‘Back’ expecting to go back to the app but instead the ‘back button’ is overloaded to mean ‘up to parent’ by the mail app so I actually end up in the inbox. It may seem a small thing but believe me it is absolutely infuriating.

Unfortunately for designers precisely the converse is also true… one of the best UI design ideas is to conflate related ideas. Yes, mutual contradiction at work.?

Consider e-mail and facebook messaging, both are basically the same and wrapping them all up in the same ui would make most users pretty happy.

The challenge for the designer then is to locate ideas that seem related not only to the designers of the world but to everyone who will pick up their creation. When they succeed the user sees the world as simpler, more obvious, and less stressful. When they fail the UI seems to be a nightmare to use, a frustration, and often reason enough to seek alternatives.

Moral: Conflate with care!

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand

Looking back on previous work
Click to expand

So, over the years I’ve done some interesting work (or at least some time consuming stuff 😉 ) and I thought it might be interesting to gather a few of those items together on my new site, to begin with I’d like to highlight a couple of my early web designs.

C&W Creams

From 2004 this design was for a small American family business selling a special moisturiser to the female market. The site was a simple no-nonsense construction using css based navigation (at the time that was relatively cool, nowadays no-one would consider it anything special… how times change) consisting of 7 pages.

TaxTime

Keeping the minimalist information driven theme I also created this framework for an American tax office, unfortunately this wasn’t what they were looking for at the time so now it exists only as this mock up. I guess you win some and loose some…

So there you have it, a simple post with a couple of designs in it… if you like to see this sort of thing do let me know and I’ll see what I can do.

see also

You must be logged in to post a comment.

community content (no approved comments so far)
Click to expand
Design and Content © Copyright Duncan Kimpton 2010