Carl Franklin

.NET Wonk

User Interface Layers

I've always wanted a development environment that would let me create user interface in layers, just like you create a composite graphic in photoshop. Kind of. Read on.

This is purely a feature to benefit the end user. Too often when I am using a program for the first time, I just want to figure out the basics first, then gradually learn about the powerful features that the software has lurking under the covers.

The problem is the UI to access ALL the features is always enabled by default. This can be completely overwhleming and be a real barrier to my productivity. You can imagine an audio recording program coming up with a Record button and a Play button only. Once I'm convinced that the program actually works, I can go to the next level, where I get basic editing toolbar buttons and menu options. I can keep increasing this level as I get familiar with the features of the program, and it doesn't seem like I have to know everything all at once, which is usually the case.

You could see how this approach would be benefit new users of Visual Studio itself! Or even (dare I say) Office!

Here is an example of an application that uses these levels.

It's a simple text editor. This is the beginner screen. The File menu lets the user open and save a file.

If you click the button, you get the “pro“ UI, which gives you access to an Options screen, and counts the number of characters as you type, displaying it in the status bar - OK, it's lame but it's the idea that's important here.

Finally, if you click the button again, you get the Expert UI, which includes the daunting toolbar, and lots of other features - not shown :-)

The trick is how do you make this stuff easy to develop? It's a chore to do all this UI enabling/disabling manually with code. See for yourself - click here to download the source to this program (VB.NET 2003)

So here's my idea for how this can work in VS.NET

Imagine that - when designing a form in Visual Studio.NET - the current form's tab in the tab strip (across the top where you select the document to edit) lets you add “layers” which you can navigate with sub-tabs like so:

So...

You start designing layer 1. Build the UI for the basic fundamental features. Not overwhelming the user with options, and directing them to the most critical feature or features.

Then, right-click, add a layer, and now you can add more UI for the next level of complexity. You get all of the UI in the previous layers, and it's all on the same form. I'm not talking about transparent layers, but different “levels“ of UI. Think of it as setting the Visible property of the desired controls on and off (to simplify to the extreme).

In other words, when you're editing the UI for layer 3, you have access to ALL the controls and ui. When you click on layer 2, all of the things you added in layer 3 disappear!

I imagine the code to switch between the layers would be something like this:

  Me.UILayer.Increment

or

  Me.UILayer += 1

or

  Me.UILayer = 2

Now you have a rapid application development tool for building a layered user interface with no more difficulty than it takes to build the entire interface in one layer. There is no downside to the developer, and there is a serious benefit to the end user, and by extention, the developer's company makes the most useable software in its class.

Thoughts?

Posted: Dec 06 2003, 04:10 AM by Carl Franklin | with 76 comment(s)
Filed under:

Comments

Paul Russell said:

Kind of like building 'n' layers of UI and using some slider principle to toggle views?
# December 6, 2003 6:59 AM

Ron Green said:

I really don't think the end user is going to like this. It's one thing to have controls on the page the user doesn't understand but it's quite another to have a constantly changing interface. And human curiousity is going to take over at some point and the user is going to keep clicking the button to see what it does.
# December 6, 2003 10:45 AM

James Steele said:

I like the idea Carl. This would also give us the capability of activating/de-activating features based on user roles.

Can't wait to see the comments posted by the VS.NET Program Managers.
# December 6, 2003 11:30 AM

Jason Kohlhoff said:

That's good point James. I don't think it's UI layers that we really want though. What if you want to allow the user or administrator to choose what features they want to see? What if you need to do a roles based security type thing and (de)activate, hide/show controls based on domain group membership, some config in a database, or the registry? You can't simply lump everything into a "layer" and achieve these features, because you'd need to have more fine grained control.
# December 6, 2003 12:26 PM

JonW said:

The idea of having UI's that differ for different abilities of users is appealing until you find out that nobody will ever select the beginner UI - its a big old ego thing. You might as well be calling them stupid.

That said I'd agree that the UI design bits of VS.net need work. Particularly web forms - doing HTML layout in a tool that is markedly inferior to the Dreamweaver of 3-4 years ago is really shitty.
# December 6, 2003 1:36 PM

Carl Franklin said:

> It's one thing to have controls on the page the user doesn't understand but it's quite another to have a constantly changing interface <

> The idea of having UI's that differ for different abilities of users .. <

I think some of you miss the point of this.

UI Layers are not a security setting and nobody expects any user to "pick" a layer and stay with it. Nor are we talking about radically altering the UI from one layer to another.

I'm talking about incrementally adding UI elements that require a gradually increasing learning curve for the purposes of getting the user USING all the features as quickly as possible.

The goal is to have the user at the highest level and staying there.

I bet you dollars to doughnuts, however, that usability testing will prove that gradually "introducing" users to features in the right order will signifigantly decrease the time it takes your average user to become proficient at using complex applications.
# December 6, 2003 3:15 PM

Tim Marman said:

I'm not sure I like this idea that much. Besides the fact that Jon points out - nobody wants to be "beginner" - you're just presenting them with another choice.

And you're presenting them with this choice because your UI is already confusing?

I can envision the calls already from my older relatives if this ever made it into Office.

Plus, you kind of already have something like this in menu items. It filters out the things you don't use often, and while in many respects this is a convenience thing, it also effectively hides the "complicated" aspects of the application that the user doesn't use yet.

Although if you did go about this route, I think we should build AI to "learn" the level of the user and essentially have adaptive UI. If you don't f'up and seem to be doing well, gradually add features.

It's like those computer adaptive tests - give them a middle of the road question, see if they get it right. If they do, you trust them a little more and give them a harder one. If they don't get it right, dumb it down a bit.
# December 6, 2003 3:39 PM

Carl Franklin said:

> nobody wants to be "beginner"

Maybe a better approach is to give them books for "dummies". Nah - nobody would EVER by a book that labels you a dummy... would they?
# December 6, 2003 3:42 PM

Mark Erikson said:

Interestingly enough, this is what my senior project revolves around. We're writing a C++ IDE that can have features enabled incrementally (debugging, syntax highlighting, etc). The approach we're taking is basically an integer bitmask that the professor can generate to authorize features, then hand out to the students. Once a feature's authorized, the user can see it listed in the options and enable. Obviously, it's not the most secure approach we could be taking, but it should suffice for now.

As far as the designer support, I must say it does sound rather useful. I don't know if it would be used enough to make Microsoft's time creating it worthwhile, but it'd be cool nonetheless.



Mark Erikson
mark dot erikson at cedarville dot edu
# December 6, 2003 4:20 PM

Billy Hollis said:

The idea has merit for a certain range of applications, and is probably more applicable to commercial applications. I’m not sure that most applications need it. But flexibility is good if it doesn’t get in the way when you don't want it.

One easy way to implement this is with Extender Providers. I could do a base form than contained this functionality using an Extender Provider in a half hour or less, with each control’s minimum UI level settable in the property window. Should I do an MSDN article showing that solution? I’ll credit you as the idea originator.
# December 6, 2003 4:49 PM

Eddy Recio said:

I think the idea definitely has merits. It also shares insight into what the future should be like where UI's are adaptive to how people are best productive and one design does not fit all.

I often take a more task oriented apporach of asking what they might want to do next, making some assumptions, kinda like Win XP and the Side task pane. Having said that I almost wish you could turn this feature of XP off for advance users that want that screen space back.

Having previously said that the idea has some possibilities, how do you suggest going about implememnting such an idea. Are the layers composed of metadata, that can be configured on use, experience, etc? So would this perhaps be achieved by VS.NET creating mulitple .resx files that perhaps inherit from each other? I have lots more questions, but I'll leave it at those.
# December 6, 2003 4:53 PM

Carl Franklin said:

Billy,

Sure, go right ahead! Publish a link to this blog entry, if you don't mind. :-)
# December 6, 2003 4:53 PM

Carl Franklin said:

Eddy,

VS.NET just has to keep track of which controls/menu items are visible in a given layer, and to make sure that when your app switches from layer to layer that the new controls "appear" in a way that doesn't screw up the layout - i.e. drawing controls on top of each other.

CONCEPT CHECK: All the code is always there. All the UI is always there, it's just that both at design time and runtime, certain objects are invisible.

The designer UI simply needs to let you build a complex app in stages, but instead of forking the code (that would be bad) we need to quickly go from view to view or layer to layer.

I really don't think it's a complex task.
# December 6, 2003 4:59 PM

Carl Franklin said:

Now that I think of it, maybe a property of System.Windows.Forms.Control called Layer, which is 0 by default (there is always a layer 0) and can be set to reflect the layer that the control lives in.

I'm not sure who owns the logic to turn control functionality on and off. I suppose both the form (or container) and the control to some extent, although I haven't thought it through yet.
# December 6, 2003 5:12 PM

TrackBack said:

# December 6, 2003 5:32 PM

julie lerman said:

Very cool idea Carl. I always love the way you are thinking out of the box. So first of all, my mom and dad would be VERY happy with an application that let's them start out as a beginner. No ego problems there at all.

I will have to look at the code because my brain is already whizzing through all of the possible ways to implement this. Talk about an extensible framework. God - think XAML. That's what would enable a thing like this. You don't have to change the CODE just the face.

Oh Carl, how can you do this to me? I've already got a gazillion client projects and pet projects on the burner! :-)

Now this is inspiraton to go out and get a longhorn box and get snowed in!!
# December 6, 2003 6:04 PM

Joel said:

How about extending the idea to security groups? Layers representing security levels - almost the same thing.
# December 6, 2003 6:28 PM

Not really new.... said:

While I like the idea of providing different UI capabilities to different users I don't think it is a new idea but rather something we should all be doing...more or less explicitly.

As an example of an explicit approach the UI of the Calculator app in Windows can be changed using the menu View|Standard or Scientific.

It other applications the access to advanced features/behaviour hidden away behind Option or Advanced buttons/tabs.

/Chris
# December 6, 2003 6:39 PM

Carl Franklin said:

Chris,

I agree it's not a new idea, and we have always had the ability to code this feature explicitly, as I did in the sample project above.

I'm proposing that the designers in the dev environment give us the ability to create an "incremental UI" without having to write a great deal of plumbing code.
# December 6, 2003 6:50 PM

Rory said:

"The idea of having UI's that differ for different abilities of users is appealing until you find out that nobody will ever select the beginner UI - its a big old ego thing."

I think you're right if we're talking about developers - Developers definitely have ego issues when it comes to being considered "Beginner/Pro/Expert," but end users just want something simple and easy regardless of the label. There's nothing particularly insulting about "beginner" status anyway. All it indicates is that you're new to a system, which isn't even remotely the same thing as calling somebody "stupid."

While it's entirely anecdotal evidence, I *do* know quite a few people who wouldn't mind being called "begginers" at all. Rather, they might find it rather comforting. Seeing a "beginner" setting might make them feel as though the developer actually *considered* that there might be non-expert users at the helm. Far from being insulting, I would think this to be a sign of compassion in an area that has traditionally been rife with "bad vibes" (developers meeting with users often result with both sides swearing at each other - it doesn't *have* to be like this).

Also, this whole UI layering thing isn't something you'd have to stick in every app you write, but it would be pretty sweet to have for the times when such a system would make sense. I've certainly written apps for which a layering system would have been appropriate.

Anyway, I think it's more important to give a user a good experience than to worry about egos.

I've been playing "Simpsons Road Rage" on my X-Box all afternoon, and I've been playing with the "tutorial" mode turned on. This means that I am presented with the occasional dialog box explaining a concept of the game with which I might not yet be familiar. It's a silly example, but it's helped me get the most out of the game in a very short amount of time. I find the feature very useful, and don't mind the implication that I'm not an "expert" "Simpsons Road Rage player." You may feel differently, but I wanted to express that there *are* those of us who *like* a little bit of hand-holding at the outset.

Just my two cents. I'll probably be back in a little while when I get some more change...
# December 6, 2003 7:22 PM

Rory said:

"While I like the idea of providing different UI capabilities to different users I don't think it is a new idea but rather something we should all be doing...more or less explicitly."

I was thinking about whether or not this idea had been implemented in other apps, and then I realized that it doesn't matter.

It doesn't matter because it certainly hasn't been *widely* implemented, nor has it been implemented in the user-friendly manner presented here.

Also, the solution goes beyond just the user experience - there's a benefit to the developer here, too.

One of the major differences of Carl's idea seems to be the integration at the level of the IDE. Doing it "Carl's Way" is like the difference between assembling a car piece by piece in a barn and using an assembly line.

Part of the innovation here is the *process*.

At least that's what I think...
# December 6, 2003 7:28 PM

milbertus said:

I definitely like this idea. To some extent (at least with complex apps), when I use an app for the first time, I don't try and go through all of the options and figure out what I want set to what - I play around with the app, and set the options as they come up.

This will just be a way of formalizing that process. I could start with the Beginner UI, and gradually work my way up to Expert. While this progression may be fairly fast for me, it doesn't have to be that way for everyone.

While the term "beginner" may be insulting for some users, it's not like these descriptions are set in stone. The label doesn't matter as much as the concept, of allowing the user to learn the app at their own pace.
# December 6, 2003 9:24 PM

Bruce said:

If the word 'beginner' bothers you - try "simple" and "complex". That skews it the other way.
# December 6, 2003 11:41 PM

Adam Hill said:

As a developer I would like this functionality in the IDE as well. And I have developed many apps where there were multiple user roles that only differed by what controls were visible.

We already have PageNavigation in the Framework, PageLayers could be a step in the "removal of 2/3's of the code" direction.

Now if we could *animate* the opacity of controls fading in/out we would have coolness as well :)
# December 7, 2003 12:48 AM

Carl Franklin said:

Gang, don't think that the "idea" is to put a "Beginner/Pro/Expert" button on every form. That's just a demo. The important thing is that you have programatic control over when, how, and under what conditions to move through the layers.

If you want to "decide" for the user when to do that, great. If you want to let the user control that, great. If you want to bug the user about it "Do you want to be able to do such-and-such.." that's ok too.

It's the designer and the programatic control that I'd like to see developed.
# December 7, 2003 5:21 AM

Steven M. Cohn said:

I'm sure this has merit and probably has a limited use for applications that may be used by a wide range of users; most appropriately software development applications that target both students and developers with decades of experience behind them.

Not to burst your bubble, but this really isn't any different that what the Office team did when they introduced the "Advanced view" for the drop-down menus. When you first install Office you get a slimmed down view of the menu items. But as you use hidden features (viewable when you hover of the last icon in the slim menu view) these features slowly get added to the menus. Or you can enable the full menus with an Option.

I'm afraid this would all come down to ROI. Is it really worth the development time to build a really good interface? In your layered example of your simple notepad app, what would happen in you added lots of features in level 3; what would that mean if you then went back to level 2? Would there be implicit rules that that form designer would need to follow? Would the user understand these constricting rules without a Level 3 view side-by-side? There's a lot to think about.
# December 7, 2003 7:38 AM

julie lerman said:

Steven- (If I am understanding you correctly) I think you are missing Carl's point. He is suggesting that the IDE could be making it easier for us to implement this type of stuff so that we don't have to worry about the ROI of creating user level UI's.

Sure the idea of showing/hiding features is not new. I'm sure many of us do it based on user permissions all of the time. Admins see things non-admins don't. Managers see things non-managers don't. In my case that's just making menu options visible or not, buttons visible or not or maybe a screen editable or not.

So that's where Billy's idea of the control extenders come in. Right now, I explicitly set these values when I load a page - check the user parms and basically turn visible true or false or enabled true or false. But with control extenders, you can just set the permission setting once and the extender can have the control of these properties. Generically "this control is available to GROUP X and GROUP Y". So that is a neat way to implement it already without something new in the IDE.

Well, I have to go. We got over a foot of snow and it is time to go skiing! Woo hoo!!
# December 7, 2003 9:28 AM

Carl Franklin said:

>> Not to burst your bubble, but this really isn't any different that what the Office team did when they introduced the "Advanced view" for the drop-down menus. <<

There's no bubble to burst. <g>

As I told Chris (scroll up), the idea of hiding things is not new. What I want is an easy way to DEVELOP apps that have a layered incremental UI.

If you really want to be picky, you could say that Office implemented this only in the menu structure. With the right tools, it could apply to the general work area (controls) as well.
# December 7, 2003 11:29 AM

Carl Franklin said:

>> with control extenders, you can just set the permission setting once and the extender can have the control of these properties. <<

That's true, and I wasn't even thinking of using this feature in the context of security, but I suppose that could work too.
# December 7, 2003 11:32 AM

iggykin said:

See IUI a'la Longhorn http://www.winsupersite.com/showcase/longhorn_task-based_ui.asp

Using Tasks for each screen, still enables you to have support for shortcut keys and other optioned configuration.

# December 7, 2003 2:48 PM

Scott said:

So, if you want to simulate application option layers, couldn't you create a struct/class/array containing refs to the UI controls that are contained in each layer. Then when the user clicks on the "pro" or "expert" button, you just interate through the array and set the "visible" property on each control (or if you were using a struct/class to hold the refs you could just have a methods called "show" and "hide" on the object).
# December 7, 2003 4:09 PM

Thom Robbins said:

Actually an interesting idea. This is something people have been doing for awhile. But I think the difference here is that you are actually presenting this to the developer within the UI as a feature of VS.NET.

As someone mentioned I personally, think it would be good within the context of security most of all. The idea that when you validate a user certain layers get turned off and the code is segmented would be interesting.
# December 7, 2003 4:33 PM

julie lerman said:

I was thinking more about the control extenders (while shoveling snow!). It would be hard [for me] to make them dynamic so that you could easily ADD permission groups or user levels, etc..

The experiment to do would be to compare having one control extender with multiple properties (is that possible?) or have multiple control extenders.

But I have to work on my other program now. I just can't help thinking about this. I like the challenge of how to make it work in the most extensible way.
# December 7, 2003 5:27 PM

Carl Franklin said:

I know its hard to pick out the nuggets in this post, but I'd like to see a Layer property on System.Windows.Forms.Control :-)
# December 7, 2003 6:50 PM

Steven M. Cohn said:

Yeah, I got it. I agree it would be cool to be able to build a UI as Carl described. But I wonder about the value of such a UI and how it would be adopted by users other than those who can comprehend such an advanced view of the world.

Joe User doesn't even understand that the Start menu is the same as the Start menu folder and can be viewed in Windows Explorer, IE, right-clicking on My Computer and clicking Explore. Window is bloated with redundant features to help different user levels, but in the end, it tends to confuse more than clarify. (Don't get me wrong; I a big fan.)

Of course, I could very well be proven wrong and, as I said, think it would be worth investigating. I look forward to hear if this does get adopted by Microsoft.
# December 7, 2003 7:39 PM

julie lerman said:

windows.form.control.layer=string?
windows.form.control.layer=windows.form.controls.layerEnum?
It looks like I have to cut this out and just download the damned sample! I just am knee-deep in code... :-)
# December 7, 2003 8:10 PM

John Robb said:

Why don't you just call it a layered "working" tutorial?
# December 7, 2003 9:30 PM

Rory said:

"But I wonder about the value of such a UI and how it would be adopted by users other than those who can comprehend such an advanced view of the world."

I think those users would really appreciate it. Although this might sound silly, such a feature would be a good way to say "Hey - we just want to help you out a little."

It isn't going to solve all the usability problems in the universe, but it could contribute to making things better for the big picture.

Anyway, I think the added complexity of *one* toggle button (or however it's implemented) would be worth the benefit.

"Joe User doesn't even understand that the Start menu is the same as the Start menu folder and can be viewed in Windows Explorer..."

The user doesn't know about that folder because the user doesn't need to access it.

Users do, however, use applications. I mean, there's no other reason to turn the PC on in the first place :)

Since they're already exposed to the app, and since the feature could be implemented in a very easy to use and very easy to find manner, I think that adapting to the feature wouldn't be terribly difficult - certainly less difficult than finding some obscure folder. Users are accustomed to pushing buttons, but they aren't very familiar with hunting down folders they don't use - they use that stupid Search Dog for that :)
# December 7, 2003 11:25 PM

Carl Franklin said:

I wonder how many of us have spent any time with the "rest of the world." You know, those who'se lives DON'T revolve around the PC. <g>

There are more of them than there are of us.

Case and point, the minister of my church is afraid of PCs, but absolutely has to use one to communicate by email.

She has to know just as much about using email as you I any of us. What do you think her experience of configuring and using Outlook is going to be like? Not good.

"Carl, I just installed and am running Outlook. Now what do I do?"

# December 7, 2003 11:41 PM

Scott said:

Unlike the plethora of "softies" posting here and other places, I have to design interfaces for real people. I get feedback immediately if the UI is confusing, usually a phone call or a blinking voicemail light. I have been doing this for around 10 years now. Stuff like this is nice for developers to have; 90% of the users will never use it. Stuff like this gets posted in PC Magazine as a "Windows tip and trick: Did you know you can enable advanced options in blah? Click the "advanced" button".

I think the real advantage to the layers concept, something which is not new (web apps have been doing it since the boom), is in the security context that others have mentioned. The ability to easily show/hide UI elements based on a security role would be a plus.

However, given that there are easy work arounds in the current framework that would simulate this sort of thing, I'd rather any .NET Framework guys at MS working on this turn their efforts toward making a DataGrid and DataSet that not suck rather than adding a .Layer property to WinForms/WebForms.
# December 8, 2003 1:50 AM

Rory said:

"Unlike the plethora of "softies" posting here and other places, I have to design interfaces for real people."

Well - Let's be fair here... Owning the vast majority of the desktop market, MS is absolutely developing interfaces for real people.

It shows, too.

There might be flaws, but MS isn't alone in making the odd mistake or two. I get really frustrated when using my Mac sometimes because I've found that, depending on who coded what app with what technology, different *common* meta-key combos do entirely different things. It's maddening. I certainly haven't encountered anything like this in Windows.

Granted, like most of what I write in comments, this "evidence" is anecdotal, but let's not pretend that MS coders aren't developing for "real people."

"However, given that there are easy work arounds in the current framework that would simulate this sort of thing, I'd rather any .NET Framework guys at MS working on this turn their efforts toward making a DataGrid and DataSet that not suck rather than adding a .Layer property to WinForms/WebForms."

It's not like .NET is the product of five coders crammed in a room. It's entirely possible that the people who deal with the DataGrid aren't the same people who would implement a feature like this.

Of course, I have no idea what I'm talking about since I haven't seen MS's operations, but it isn't a bad guess.

Point being, it *seems* like a good idea that would be totally innocuous - if you don't want to use the feature, then you certainly wouldn't have to.

The ad hominems are just a distraction from the issue which is simply: Is the feature good or not?
# December 8, 2003 2:25 AM

Ivan Towlson said:

Raymond Chen's note "Why doesn't Windows have an 'expert mode'?" (http://blogs.gotdotnet.com/raymondc/permalink.aspx/cc8dd84f-7605-4145-bd4b-26413e507b02) is relevant to this discussion. Okay, he's talking about the problems with a global setting across a very diverse environment, whereas Carl is talking about a specific application, but worth a look all the same.
# December 8, 2003 4:11 AM

Carl Franklin said:

Ivan,

Great post. I agree that it can't work at the OS level. Just because I'm new to application X doesn't mean I'm not a whiz at application Y.
# December 8, 2003 4:48 AM

Scott said:

Rory,

I'm not sure that this feature IS totally innoculous. By including a "Layer" property, you also have to include a "Layers" collection for the WinForm, which means a default Layer has to be present for all the controls on the form to go into. You also have to include some sort of z-layer like property in the layer to handle overlaps. Not to mention an overhaul of the visual designer in Visual Studio to handle the layers. I don't know how big of a deal that is since VS is closed source :), but given how slowly things move at a large corporation I can't imagine the change would be trvial. Given that there are other ways to implement this in the current framework, it wouldn't get a high priority from me on a new features list. It's kind of a pseudo control-array wrapper for the "visible" property.

The ad hominems were actually making a different point, it must have been a murkey one though. Even if Microsoft implements the layer feature and we have the ability to turn off/on parts of the UI based on experience level, most people won't use it or even know the "expert" interface is there. I've been using MS technologies since DOS 4.0 and I'm STILL finding little nuggets and features in apps like Word and Excel. Features that some developer locked away in an office with only enough room under the door to slide a pizza, thought was the most important feature. One that everyone would want.
# December 8, 2003 10:49 AM

Carl Franklin said:

>> You also have to include some sort of z-layer like property in the layer to handle overlaps <<

Layers are not on top of each other (as in photoshop, for example). They are stages of UI all on the same z-axis. Microsoft already has anchoring and docking features of controls that prevent them from stepping on each other.

>> Even if Microsoft implements the layer feature and we have the ability to turn off/on parts of the UI based on experience level, most people won't use it or even know the "expert" interface is there. <<

That's assuming that the layers can ONLY be promoted by the user, which has nothing to do with the layer technology. That's a decision the programmer makes. A good program will determine when it is time to promote the UI.

How hard would it be to ask the user after so many days of use?
# December 8, 2003 10:58 AM

Mark Kenyon said:

Already begging for this functionality, tho I didn't know it. My software handles 3 different types of jobs, tho very similar. I have a clunky way of handling which controls are viewed for which type of job. I'm programmatically creating the text boxes I need, even tho some of them are the same regardless of the job. I could use a layer for each job with certain controls for all layers.

BTW, I hate the hidden menu controls. Bugs me right up a wall when I am talking to a user and say 'Click on Open' and they say 'I don't see open' and all it is is they have to click those stupid double arrows.
# December 8, 2003 11:30 AM

Scott said:

Good point about the user being prompted after so many uses. Although I don't know that I would tie it to a time interval, but maybe a usage or function level. e.g. if(advanced_functionality_exists_for_task) -> prompt the user about displaying/tutoring them in the advanced functions. That could annoy some people though. "This darn computer keeps asking me questions every time I try to do something!"

I think that programatically a layers property would make it easier to show/hide controls (which is really what we are talking about, not enabling/disabling functionality) based on certain conditions. But I think it's already possible and not difficult to implement now, so it's not something I would clamor for (if you're soliciting opinions, if not "/ignore Scott"). Plus I'm already doing things like this in ASP.NET and haven' had to do much WinForms programming, so that may color my thinking somewhat.
# December 8, 2003 12:26 PM

Steve said:

I want to throw a contrarian view out there. It would be a bad idea to make this easy. Task based UI is a great idea. Having layers as a metaphor to allow drag and drop building of dynamic UI rather than forcing the developer to code is not bad.

But the original idea of multiple modes that get switched on the user is horrible. HORRIBLE I SAY! :-) I can't say how frustrating it is to find a cool feature only to forget where you found it. Add on top of that the need to know what mode you've set your App in, or for goodness sake what mode it decided to auto-select for you! There are lots of different ways people remember things, and moving stuff around dynamically penalizes a large portion of the population that might recall things spatially.

Having a tutorial, programmatic help, or comprehensible UI for a beginning user/player is not the same thing as having a visually different UI based on a mode setting. I think some recent games show good ideas in this direction. People aren't forced to use games so bad UI is punished there more than other areas. Knights of the Old Republic (I played it on the Xbox) had a great automatic introduction to the controls as it introduced you to the tasks at hand. I think looking at game UI is a good place to see experiments in UI succeed or fail.

It sounds like this feature would make it easy to create horribly complicated software puzzles that would serve to frustrate and confuse users. Add on top of that multiplying the test matrix for the now easily created modes, and I'd argue you have a recipe for losing sight of the issue (an unapproachable UI) when the resulting problems in additional bugs, documentation, etc start to roll in.

That said, the spirt of this discussion ... how to aid developers in creating approachable UI, is great. I just think automating the creation of modality in the presentation layer is the wrong direction.


# December 8, 2003 1:02 PM

Mark Kenyon said:

Well, in regards to Steve's comment, helping developers create the UI is great. It should (and in many other features of programming, is) be the responsibility of the programmer to ensure ease of use with the tools he has at hand. (Because a gun shoots a man is the gun at fault?)

'Sides, if somebody makes a poor UI, nobody will buy it, or his company will either can him or tell him to shape up.
# December 8, 2003 3:33 PM

Rory said:

"I'm not sure that this feature IS totally innoculous. By including a "Layer" property, you also have to include a "Layers" collection for the WinForm, which means a default Layer has to be present for all the controls on the form to go into."

I might be wrong here, but it seems to me that it could just be assumed that a layers collection with less than 2 layers already has a default layer (i.e. - the *only* one). I don't see this as being a major impediment.

"I've been using MS technologies since DOS 4.0 and I'm STILL finding little nuggets and features in apps like Word and Excel."

DOS 4.0? Newbie :) Been booting DOS on a floppy since 1.1, thankyouverymuch.

And, you wouldn't even have to worry about those little "nuggets" in Word/etc. if you had a "Beginner" setting.

I'm still thinking that this is a pretty harmless feature that would be a great "nice-to-have"...

I understand where you're coming from, though, and I think the opposition is good. I'm a supporter of this layers idea, but I find it really interesting to hear why someone *wouldn't* want a feature like this.
# December 8, 2003 5:12 PM

Rory said:

"But the original idea of multiple modes that get switched on the user is horrible. HORRIBLE I SAY! :-) I can't say how frustrating it is to find a cool feature only to forget where you found it."

While I agree that it would be frustrating to find a cool feature and then forget where it came from, I'd like to point out that this shouldn't be a problem with the multiple-modes feature.

If the user starts out in "Beginner" mode and increments the complexity of the UI sequentially (Beginner, Pro, Expert), then the user theoretically shouldn't encounter any features that he or she will forget - if I understand Carl's idea properly, then the UI is always added *to*, but not subracted *from*.

By the time you're ready for "Pro" mode, you should know the "Beginner" UI pretty well.

It would be like playing a game of "Concentration" first with 4 cards ("Beginner"), then 8 cards ("Pro"), and finally 16 ("Expert"). As cards are added, you *will* lose a little bit of context, but you should still have a generally good idea of where the old cards were.

'Course, this might all just be the caffeine talking :)
# December 8, 2003 5:18 PM

Mads Kristensen said:

Carl, I like your idea and have been looking for something like it for years. I startet out in web development, and html have allways been able to do layers. It's a common thing that I use every day developent asp.net pages.

You should maybe think of layers as placeholders for UI elements that you can turn on and off (or altered) depending of events triggered by e.g. the user. That's how web developers use layers. Can't see the fuzz about security having anything to do with layers???

Maybe your example is confusing, but I understand it as purely a design feature. Not a beginner, pro, expert feature.
# December 8, 2003 6:41 PM

Steve said:

My source for concern is that this is counterproductive modality.

I don't agree with everything Raskin has to say, but I think he is spot on with respect to modality.

http://humane.sourceforge.net/humane_interface/hollands_review.html

Beginner,Pro,Expert makes for a more complicated (and modal) user model that arguably outweighs the benefits gained from restricting the problem domain with a UI mode.

Can't the problem domain be restricted without resorting to modality? Use a task based menu? Take a look at Digital Image Pro - it has a secondary task based menu along the side that accomplishes the same goal of UI approachability without limiting the available functionality.

Example user issues with the modality:
Unless Beginning, Pro, Expert modes are common across all applications it cannot be considered something the user will know about.

How does the user figure out a feature they want is available, but they need to change mode first? Why should this discovery be necessary?

What happens when an expert solves a problem for a beginner? Should they leave it in expert mode so the beginner can solve it themselves next time? What is the model for incrementally learning the application when the UI radically changes twice on the way to expert?





# December 8, 2003 6:45 PM

Carl Franklin said:

>> BTW, I hate the hidden menu controls. Bugs me right up a wall when I am talking to a user and say 'Click on Open' and they say 'I don't see open' <<

I don't envision people going from a more complex UI back to a more simple UI, which is what you have there. Again, my idea is to just give the user a way to become proficient more quickly, and never look back.
# December 8, 2003 7:09 PM

Carl Franklin said:

> Maybe your example is confusing, but I understand it as purely a design feature. Not a beginner, pro, expert feature. <

That is exactly how I see it. Everyone has glommed onto the beginner/pro/expert thing, when that is just the silly demo part of the whole deal. I don't care if you call it apples, bannans, and fruitcake. It's stages - layers of complexity. I feel like I've been making the same post over and over again.

It's not about beginner/pro/expert, ok??

# December 8, 2003 7:17 PM

Steve said:

I might be confused. But I think I acutally just disagree. (Though my opinion on UI can definitely be taken with a couple grains of salt.)

>The problem is the UI to access ALL the features is always enabled by default.<

That is the statements I don't agree with.

I believe that easing the learning curve of a UI without disabling access to any features is always a better alternative.
# December 8, 2003 7:58 PM

Carl Franklin said:

Is that because you can't imagine being a regular user getting overwhelmed by a complex UI?

I take people's word for it when they tell me software is too complex.
# December 8, 2003 8:37 PM

Sean Gerety said:

I like the ideal. And here's where I'd use it. Outlook. There's really only about 3 or 4 buttons that I use on a daily basis, however I've probably got 25 buttons and other items on the toolbars. I'd like to reclaim that space (can you tell I work on a laptop?). And only when I need those advanced items would I show them.

This is kind of along a line of another control I'd like to create called a cabinet control. Think of the XP drop-down menu, but that concept would be used on a toolbar. Show me the items I use alot (or pin, a la the Start menu in XP) and when I hover over the ">>" icon show me all of the toolbar.

Sean
# December 8, 2003 9:27 PM

TrackBack said:

# December 9, 2003 12:59 AM

Scott said:

I am starting to warm up to the layers idea some, it could just be the effects of the gas they pump into the air in Redmond. I just got back from the Scott Guthrie show at the Microsoft conference center.

I think most of us realize that the idea can be extended beyone just a simple "beginner, pro" UI modification. I don't think the layers property adds any value to the users experience inherently. I think it provides a shortcut for the developers that they can use to enhance the users experience. I think the most obvious practical uses are both the user configurable UI (think of the users being able to select out things they don't care about then being able to hide them with a single method call.) and for security purposes (think of a firewall configuration applet that will display the ports open, but hide any buttons (or kb hotkeys?) that would allow the user to open ports up).

Adding a layers property would require a change to the visual designer, unless it was a pure pseudo-control array type of construct and didn't have anything to do with the presentation.
# December 9, 2003 2:28 AM

Ifeanyi Echeruo said:

Navel gaze all you want no one really knows for sure about these things until they are tried.

We could blah blah blah about the pros and cons or we could download a first stab at providing VS.NET designer support and give it a shot.

http://nand.net/~iman/LayeredUI/FilteredUIApp.zip

Its a VS.NET solution with 2 projects in c#
one is a Library providing designer support and the other is a test app

The library provides a ControlRoleProvider component. When the component is added to your form then a string 'Role' property becomes available to all controls in that form.

The ControlRoleProvider itself has a Roles collection (StringCollection) that defines all available roles eg {"Basic", "Advanced", "Expert"}

When your application wants to display "Basic" UI then ControlRoleProvider.Role = "Basic" should suffice. Likewise ControlRoleProvider.Role = "Advanced" will display "Advanced" and "Basic" controls. etc

As a convenience int ControlRoleProvider.RoleIndex can be used to cycle through roles.

You of course almost never see any of this using the designer. Enjoy

P.S It's a lil rough around the edges this was a saturday afternoon sunday morning thing

# December 9, 2003 4:36 AM

Carl Franklin said:

I love the Internet! I can't wait to check this out!
# December 9, 2003 8:07 AM

Bryan Batchelder said:

I saw two people mention "Control Extenders", which on subsequent googling came up with very little. Anyone care to enlighten me on this? From what I can tell they are non-visual components that get linked up to a control...but do what? Thanks, Bryan.
# December 9, 2003 6:07 PM

Carl Franklin said:

An good example of an extender provider is the ToolTip control. When you add it to the form, all the controls on the form get a new property "ToolTip on ToolTip1". The new property is attached to all the controls but the implementation is in the ToolTip1 control.
# December 9, 2003 6:39 PM

Josh said:

I guess I should have read the comments before going off and spending an hour coding up a solution. Looks like a lot of people already realized it could be done using an extender property, and have created an implementation.

My implementation differs from the one described by Ifeanyi Echeruo, because I stick with an Integer value for the Layer property. I believe that allows you to more easily "stack" layers. If a control only has one layer property, it can only belong to one layer. Using an integer, you can say an control with a Layer = 3 will show up on every layer 0-3. My component that provides the Layer property also has its own property, CurrentLayer. This provides the interface for the developer to change the layer. In the property "set" method of CurrentLayer, it loops through all of the controls on the form and sets the control's visible property to true if it's Layer <= CurrentLayer, otherwise it is set to false.
This was just a quick-hit solution, as using the Visible property in this way wouldn't be reliable. What if a control's visibility is controlled by some other programmatic means? Just because a control is on a layer that is visible, doesn't necessarily the control should be visible at that point.

Bryan - try googling for IExtenderProvider. That's the interface you need to implement to create one of these things.

Ok, I feel like I'm doing my own MSDN article now. Carl, I apologize for using your webspace for my own streaming thoughts (I'm blogless), but I love your idea, and firmly believe that a usable solution can be created WITHOUT waiting for Redmond to implement it.

Anyone want to start a GotDotNet Workspace to do this? joshuaflanagan at yahoo dot com
# December 10, 2003 11:21 PM

Carl Franklin said:

Actually, Billy Hollis is the guy to help you. He's got a lot of time with Extender Providers. I'll email him and ask him to come back to the blog. :-)
# December 11, 2003 12:15 AM

Patrick Hynds said:

This concept has a wonderful benefit if you are developing applications that are either licensed at levels or that users play different roles with different workflows.
# December 11, 2003 9:17 AM

Russ Fustino said:

So one question... does the newest layer inherit all of the prior layers or is it independent on it's own?
# December 11, 2003 2:31 PM

Carl Franklin said:

Yes, exactly. the highest layer inherits all the objects from the previous layers.

Carl
# December 11, 2003 2:37 PM

Ifeanyi Echeruo said:

Oh boy this is getting long winded. At this rate the blog is going to need a newsgroup ;)

Josh - my implementation does what you describe under the hood. It uses an integer property to mark layers. And multiple providers can set different layers on the same object without clobbering each other.
The layout provider keeps the dirty laundry under wraps but publicly maps the integer to the order of strings in the Roles collection. Given a Roles collection Dad, Mom and Bob; at layer Dad only Dad is enabled but at layer Bob Bob, Mom and Dad are enabled.

The reason for using strings to label layers would be the same reason you would want to use enums in code for constants.

You're quite right about the fight for visibility. if you make an item invisible in code and later switch layers that item's visibility is clobbered. The solution?

I could only think of two

1) Dont give the item a layer. If SetRole is never called on an object its hands off for the layer system. I guess that means IRoleProvider needs an UnSetRole

2) Provide a second property 'layer visibility'
It is a shadow property that indicates what Control.Visible 'should' be. Every time you want to change Control.Visible and it does not match 'layer visibility' you know someone did something behind your back. Leave the control alone until 'layer visibility' and Control.Visible match

PS - I mix the terms 'layer' and 'role' cos as I wrote the code role seemed a more natural term, layer was kinda ambiguous. Role is a crap term it's as ambiguous as 'paradigm shift'. So I'll be changing everything back to 'layer' in the code as soon as I get a chance
# December 11, 2003 11:45 PM

Carl Franklin said:

Ifeanyi,

I finally got the chance to run your code. Wow! This is exactly what I was talking about. Everyone interested in this should download his project at http://nand.net/~iman/LayeredUI/ (or just click on his name above).
# December 12, 2003 2:04 AM

alan@cooper.com said:

Carl,

Thanks for inviting me to participate.
---------

All of this is predicated on the assumption that the quality of a program's behavior is somehow related to its collection of functions. That is not true.

A program can be well-behaved with lots of functions, and it can be ill-behaved with few. What makes a user interface good or bad isn't access to more or fewer functions.

A program with good interaction will allow its users to direct it the way you direct your car down the street, not the way you select functions on your home entertainment system (which are univerally poorly designed).

Programmers must solve software construction problems by deconstructing user scenarios down into their constituent functions and then coding them up as such. But to then turn around and present that same scenario back to the user as a decomposed heap of vaguely-related functions does not work very well for the user (notwithstanding the fact that it might work just fine for the programmer). Dividing that decomposed heap up into several--conditionally-hidden--smaller heaps misses the point.

There's a big difference between good programming doctrine and good design doctrine. One does not necessarily imply the other.

Thanx,
Alan
# December 13, 2003 4:02 PM

Carl Franklin said:

This is absolutely true. Alan makes a great point that we ought not to forget.

What I'm describing is a tool to make a particular type of user interface. Just because you use the tool doesn't mean you will design the right UI. Even if you do design a great UI it doesn't mean people will use it, and no tool is a substitute for thinking through the process of making a great UI.

A MUCH more important question than "how will we create a layered user interface?" is "What does the user need to DO with this software, and what will their experience be."

So if you are committed to developing the BEST UI possible, and you decide to using a layered UI tool, your work is just beginning. And, if you were smart, you'd want to get an experienced designer's help.
# December 14, 2003 6:20 PM

private Krankenkasse said:

Really cool Idee! Ralf
# January 27, 2004 6:23 AM

TrackBack said:

# February 1, 2004 11:45 PM

rtyecript said:

I really liked the article, and the very cool blog

# August 23, 2011 1:19 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)