A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I've been googling unsuccessfully for information on a particular user interface design pattern without success. I doubt if I've invented somthing particularly new so I'm probably just using the wrong name fto search for it. Briefly the pattern is as follows:
The application keeps track of a collection of related objects of interest which I'm calling the users "Context". The user interface has various screens display particular types of objects and lists of those objects types. When you switch to the screen for a particular object type the application reads the context and executes a default search based on whats in the context. Also either automatically or by some user action the user can take the currently displayed object and load key information from it into the context. Since the objects in the context are related this might require cascading changes to the context.
As a simple example in a CRM application the context would include the account number. Switching to a screen displaying contact information would execute a default search to find all the contacts for the account number so that the application would by default list all the contacts for the current account. The user might then execute a search for contacts by name and upon finding the contact he is interested the context would be updated with the account number of the contact he found. Then if he switched back to the account screen the application would execute a default search based on the context and display that account's information.
My question is what name would you give to this pattern? Where would you go to look for a discussion of it and its variations?
I've seen it described as a browser, a drawer, a slide-out and other synonyms. If there's an official name for it, I don't know. The analogy is you're looking at labels (in a list) and opening drawers corresponding to those labels, much like a physical card catalog.
However, almost every example I've seen works in one direction - it would be of little value to open a card catalog drawer, select a card, and have the cabinet itself magically resize itself to only show labels relevant to the card. (Usually that info is expressed as a "see also" directly on the card itself.)
Having said that, part of the problem is that the description provided is so vague that it's hard to think of real world analogies - and those analogies are what the design patterns tend to be named after. For example, consider this sentence...
"The user might then execute a search for contacts by name and upon finding the contact he is interested the context would be updated with the account number of the contact he found."
So if I did a search for "TheDavid", the left hand side that shows all account numbers, would list a handful of entries? And if you wanted to find my alternative point of contact, you then have to click each account? It seems to me more useful to drop the context list entirely, and just simply show me a summary each account I'm involved in, as a single page. Then you can go down and go "ah-ha, the alternative for the Main Street project is John Smith."
I hope this helps. Other people may come up with better ideas (and I'd love to hear them), but it would be easier for me to recommend a design pattern if I had a real world example.
Tuesday, February 27, 2007
Well obviously I didn't do a good job of describing the pattern. I'll try again...
The "context" is conceptually what the user currently interested in; for example "I'm interested in ABC Company". If the user goes to any screen in the application he most likely wants to see those objects related to that company. So if he displays contacts he wants to see contacts working for ABC Company. If he displays Buildings he wants to see buildings owned by ABC Company.
Typically the ability to do this would be hard coded in the user interface. For example there might be a button to display contacts for current company and there might be custom designed screen listing some company information at the top of the screen with the contacts for the company listed below it. As you scale up the application to lots of different types of objects this hard coded approach can get pretty complicated with lots of buttons and custom designed screens for different scenarios.
The pattern is an attempt to avoid this scale up problem by avoiding these hard coded user interface connections. Instead of having a button to "Display contacts for this company" you have a single global "Display Contacts" button for the application and it figures out from the current context what contacts you probably want to see.
Did I do any better or is this still clear as mud?
Sounds like what web applications use the Session and Request object maps for. Have you considered adapting that model to a GUI app?
You could probably get away with just emulating a "Session". Make a global Map object that each step of your application can access and either put objects into, or remove objects from.
When you submit one form, it stores an object (e.g. a string with an ID, for example) in your Session context. The next form then reads the value from this context and executes its default search, or displays an error if no ID was found.
Tuesday, February 27, 2007
"The pattern is an attempt to avoid this scale up problem by avoiding these hard coded user interface connections."
To the best of my knowledge, I haven't seen a pattern that does this successfully. I'm not saying it doesn't exist, I just haven't seen it. What I have seen however are maxims that suggest user interfaces should be tied to behaviors, and related tasks separated from unrelated tasks. Or to put it another way, the conventional wisdom is to bite the bullet and build a seperate interface for each... logically similar but context free task.
Sorta following Dan's example (although this may not be what he meant), the web paradigm is to have a separate template or web page for each task, instead of trying to dynamically determine the relevant controls to show. For example, you may have one template for listing companies or objects or whatever. You may have three or four different forms that are recycled whenever possible, and you may have individualized report pages.
The desktop equivalent is to have floating windows (common in OS X, X-Windows, and some applications like Photoshop), floating toolbars in some cases or literally redraw the main window to suit the task. It's very rare to see the controls themselves change within a window.
Tuesday, February 27, 2007
> My question is what name would you give to this pattern? Where would you go to look for a discussion of it and its variations?
You're asking about the UI pattern, yes? For one example of it (including some behavioural specifications), google for "CCOW" and "context management".
> I doubt if I've invented somthing particularly new <
You are correct. I have been using a method of passing context between one program and another for over 20 years.
> The pattern is an attempt to avoid this scale up problem by avoiding these hard coded user interface connections. Instead of having a button to "Display contacts for this company" you have a single global "Display Contacts" button for the application and it figures out from the current context what contacts you probably want to see. <
My method does not use hard coded UI connections at all, it is all handled automatically by the framework. Basically each screen has an area for optional navigation buttons, where each navigation button will cause a new screen to open up using whatever context has been identified in the current screen. If the current screen contains multiple entries, such as a list of customers, then the user selects one or more entries by ticking a checkbox at the start of each entry. If a navigation button is pressed then the framework will extract the primary keys of all the selected entries and put them into a string in the format of the WHERE clause of an sql SELECT statement. This string is then passed to the child form which is appropriate to the navigation button. The child form will then operate on whatever context is passed to it.
Adding options to a screen's navigation area does not require any coding as the information is extracted from the database at runtime. There is a simple maintenace screen which allows the developer to add child tasks to the navigation area of a parent task.
Because the contents of each screen's navigation bar is held on the database, it is an easy procedure to filter ths data so that any navigation button to which the current user does not have access is excluded from the display, thus avoiding the situation where the user sees a button but is only told after he has pressed it that he is not allowed to press it.
I first designed and implemented this method in a COBOL application in 1985, and I am using an updated version in my PHP framework for web applications. This method does not have a fancy name, and I have never seen anything like it described in any book of design patterns.
Perhaps I should patent it and screw the a*se off any person who copies it? (just joking!)
Wednesday, February 28, 2007
I've seen what Tony describes, but to the extent that it is tied with roles and access rights for the menuing system. Though, I don't fully understand the OP still, I think the crux of the problem is the old "separation of concerns" issue based on this line:
"The pattern is an attempt to avoid this scale up problem by avoiding these hard coded user interface connections. Instead of having a button to "Display contacts for this company" you have a single global "Display Contacts" button for the application and it figures out from the current context what contacts you probably want to see."
If something is global it may make sense to make that part of templated form. I'm cautious about saying something is global when it turns out few things usually are(a picture would do wonders here). Of course it also depends on the domain, some things truely are global in that context, but as an application grows and takes on related subdomains it's not likely to always remain true.
Wednesday, February 28, 2007
"Perhaps I should patent it and screw the a*se off any person who copies it?"
You meant "sue", right? RIGHT?!?
Not that there's anything wrong with that
Wednesday, February 28, 2007
Thanks to Christopher Wells to the reference to "CCOW" and "Context Management". That's pretty close to what I wanted although it seems to be primarily focused with connecting different applications and I was focused on connecting screens within a single application.
Using a "session" object as described by Dan Fleet is how I would probably do it. Some years ago I did medium sized display application using that basic approach. It is very popular and I never had anyone complain about the interface. But it only had 6 object types (Client, Address, Property, Assessment, Values, and Activity) so I don't really know if the approach scales up to lots of object types.
When you move to large numbers of object classes as you suggest, I think you’re going to be better off optimizing the UI to support known common tasks for specific jobs (as TheDavid suggests) by selecting the classes and attributes for each window, along with hard-coding detail subforms and drill-down controls. Otherwise, it sounds like your users are going to have a lot of overhead maintaining the contextual links and dependencies among your windows, either mentally or through a visual representation of the context. I expect users will have to maintain more than one active context at a time (e.g., finishing up a call from one customer while starting another), adding to the complexity.
That said, your idea sounds like an excellent approach to providing ad hoc querying and data exploration for exceptions to the common tasks. You could combine this ability with the hard-coded variety of UI by making the query criteria for each window a manipulable object. While the controls in your Open dialog box or Search pane (whichever you use) are optimized for the most likely queries, users are also allowed to copy and paste or drag and drop attributes (field names and values) to and from the query. Copying the account number from one window and the building ID for another into the query for the contacts window gives the user all contacts for a given account who rent in a given building. I suspect a capacity to copy and save the entire query criteria would also be appreciated by your power users assigned to handle exceptions.
Wednesday, February 28, 2007
Well its common for us IS guys to have a task oriented view of software because that historically that was what software did. But I think times are changing. Many if not most professional and management jobs are not task oriented.
My experience is that those task oriented software interfaces have a long learning curve and are not popular among professional and management staff. If software is designed that way then computer usage is relegated to their assistants. That's okay but these days there are fewer and fewer "assistants" so I think we need new designs that professional staff can use on their own.
Sounds to me like its just model view controller. The model is holding the data, the view(s) are just displaying subsets of that data.
The context switch is simply data being selected in one view, has a result displayed in another. In other words, each open view is displaying a different subset of the whole depending on which context each view is in.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz