I am writing a document in which I am proposing that our web application have both wizard-style user interfaces, and normal user interfaces.
To my mind, a normal interface in one in which you can browse a list of domain objects, and then view or operate on them as you please. This style of interface is good for creative, non-directed, interaction with the data a program manages.
A wizard interface, on the other hand, is a task oriented interface in which you first choose what you want to accomplish, and are then guided through it.
What I need to know, is what is the accepted term to describe a normal, non-wizard, user interface?
Edit: I went with "overview style user interface", but I also liked the answer "Non-linear user flow" to describe the type of interaction.
Perhaps the most widely known terms are function-oriented UI and object-oriented UI, where a wizard is a type of a function-oriented, and “normal” GUIs are object-oriented. Personally, I think these terms have been poorly defined, being simultaneously too broad and too narrow. They are also easy to confuse with implementation language.
I have suggested:
Task-centered user interface structure, where each window represents a task, or, if the task is complex, a step in the task. The layout in the window and navigation links between windows represents the task structure –what steps follow what and how tasks can branch and loop. Along with wizards, Microsoft’s Inductive User Interface and many form-type web application user interfaces use task-centered user interface structures.
Object-centered user interface structure, where each window represents one or more object classes, and the layout in the window and navigation links between windows represents the data model –how one class relates to another. For the most part, this is the type of structure used in general-purpose office software, where there’s only one class represented, typically some kind of document. If your application is a collection of record lists, master-detail forms, and/or “properties” windows that the user can “drill down” through, you’re probably making an object-centered structure.
You provide a good summary of the main advantage of object-centered structures. I’ve more on the pros and cons of each, plus methods and issues on combining them in the same app at http://www.zuschlogin.com/?p=3.
I guess the complete opposite is one long form, with all fields and options that your application supports. Mind you, you could still show that intelligently, by using the right header and collapse/expand behavior.
"Expert"
"Advanced"
"Detailed"
"Witch.".
Seriously speaking, the answer to your Q depends on the target audience.
If it is internal (designers/developer), "non-wizard" seems to be a commonly accepted term.
If it's end users, either use "non-wizard" or "advanced/expert"
Web Applications tend to be "form based". Thus IMHO the application either has "Standard Forms" based interface, or a "Wizard Forms" based interface.
A normal interface = "Standard Interface"
Opposite of wizard = "Non-Linear User Flow"
What about single-page vs. multi-page?
Related
My team has been "tasked" to create an application that follows the task-based UI (not necessarily with CQRS). I really like a UI that helps the user accomplish common tasks easily, but many pieces of this application really "feel" (to me) like a job for a typical CRUD interface (ex: all the details for a product in a catalog).
At this point, we need examples of good task-based UIs to help us see what is possible. What have you seen in the interwebs?
The easiest way to generate a task based UI is to protect all attributes/properties of your models. i.e. remove all setters.
From this (pseudo code):
public class TodoTask
{
public Date getDateAssigned();
public void setDateAssigned(Date);
public string getAssignedTo();
public void setAssignedTo(string);
}
to this:
public class TodoTask
{
public Date getDateAssigned();
public string getAssignedTo();
public void AssignTo(string userId);
}
You can't create a basic CRUD app anymore. You have to perform a task (Assign()) to update the model.
Start by removing all setters and then analyze what kind of actions (task) you should be able to do on each model.
Then you're all set.
I've blogged about it: http://blog.gauffin.org/2012/06/protect-your-data/ (scroll to the bottom to see mockups for CRUD vs Task based)
I think this would qualify as a Task Based UI.
CRUD Interfaces
CRUD interfaces have a "Save" button when editing and you miss the "reason" why something changes.
For example changing the address of a customer from "Fountain St. 55" into "Birds St. 444" has the very same semantics than changing it from "Fountain St. 55" into "Fountain St. 555". Just "updated" the street.
Task-based Interfaces
Task-based interfaces have "Action buttons" that "mean" something of the business.
For example you could have a "Correct Address" button to signify that you are changing the address because it contained a typo and the address in fact "conceptually" is the same, only that now it reads correctly. In this case the customer did not physically move.
And then you could have another different action like "Move Customer to a new address" that means that the customer actually moved to a new place and the address change carries all that meaning.
So... in short
In CRUD UIs => You "edit data".
In Task-Based UIs => You "signal that business things happened".
Conclusion
The second is always more powerful, although is harder to think in advance and the system must be flexible to add, carry and convey new "meanings" as they are discovered during the business operation itself.
But you get a huge benefit: Know "why" things mutate. In other words... capture the user's intent.
Microsoft Money 2000 was an example by Microsoft (although they call it Inductive User Interface. Here are the underlying guidelines and a few screenshots along the way: Microsoft Inductive User Interface Guidelines
I guess I don't really think of UI's having an appearance of being task-based or CRUD-based (although Dmitry's example is one that does demonstrates being task-based -- lots of commands). I see a task-based UI more in terms of how it interacts with the underlying domain and data model. If your interaction is nothing more than a typical out-of-the-box MVC application with action methods for Get/List/Insert/Update/Delete, then you're building a basic CRUD application. But if your forego those default action methods and create actions/commands that are meaningful to the application (e.g. add item to shopping cart, deactivate a class, etc.), then this gets more into the task-based UI world.
I do think it's a pretty gray line between the two.
As for an example, I know that a site that I work on (braincredits.com) is my attempt at a task-based UI. It's definitely a work in progress and I'm making changes to it to constantly improve it, but the implementation is command-based (e.g. post to transcript, add lesson, view transcript, etc.) and parts of it do use the CQRS pattern.
I hope this helps! Good luck!
i'm wondering if there is a pattern how to separate the domain logic of a class from the ui responsibilities of the objects in the domain layer.
Example:
// Domain classes
interface MachinePart
{
CalculateX(in, out)
// Where do we put these:
// Draw(Screen) ??
// ShowProperties(View) ??
// ...
}
class Assembly : MachinePart
{
CalculateX(in, out)
subParts
}
class Pipe : MachinePart
{
CalculateX(in, out)
length, diamater...
}
There is an application that calculates the value X for machines assembled from many machine parts. The assembly is loaded from a file representation and is designed as a composite. Each concrete part class stores some data to implement the CalculateX(in,out) method to simulate behaviour of the whole assembly. The application runs well but without GUI. To increase the usability a GUi should be developed on top of the existing implementation (changes to the existing code are allowed). The GUI should show a schematic graphical representation of the assembly and provide part specific dialogs to edit several parameters.
To achieve these goals the application needs new functionality for each machine part to draw a schematic representation on the screen, show a property dialog and other things not related to the domain of machine simulation. I can think of some different solutions to implement a Draw(Screen) functionality for each part but i am not happy with each of them.
First i could add a Draw(Screen) method to the MachinePart interface but this would mix-up domain code with ui code and i had to add a lot of functionality to each machine part class what makes my domain model hard to read and hard to understand.
Another "simple" solution is to make all parts visitable and implement ui code in visitors but Visitor does not belong to my favorite patterns.
I could derive UI variants from each machine part class to add the UI implementation there but i had to check if each part class is suited for inheritance and had to be careful on changes to the base classes.
My currently favorite design is to create a parallel composite hierarchy where each component stores data to define a machine part, has implementation for UI methods and a factory method which creates instances of the corresponding domain classes, so that i can "convert" a UI assembly to a domain assembly. But there are problems to go back from the created domain hierarchy to the UI hierarchy for showing calculation results in the drawing for example (imagine some parts store some values during the calculation i want to show in the schematic representation after the simluation).
Maybe there are some proven patterns for such problems?
Agree with #Marjin, and to generalise his answer. What you need is Model-View-Controller of which MVP and MVVM are variants. From your comments I think you understand that, but need to understand how to implement the pattern. Without knowing your language & target architecture it's hard to give absolute specifics. Notwithstanding, I'd start with the Observer pattern (link has sample code).
The problem you're dealing with is how to provide observable access from the domain to the UI - without encumbering the domain with UI-specific code. Observer provides a means to do that. It does require domain changes, in particular to enable registration of observers and notification of changes. However there's nothing GUI-specific in that so it stays well encapsulated.
hth.
PS: If your app is a typical thin-client web app you'll need to modify the approach. And beware: lots of web app frameworks are advertised as "MVC", but the implementation is architecturally quite different to the Observer pattern.
You can take a look at the model-view-presenter (mvp) and model-view-viewmodel (mvvm) patterns.
Fowler's presentation model includes two sample applications; it also might be of interest to you.
I think that investigating these patterns will give you some ideas on how to continue. Mvvm looks a lot like your current solution; so i'd start there if I were you.
Maybe a View Helper can help. It's not a C++, but a Java EE pattern, but in your case it will definitely separate your domain objects from their presentation details...
This is a vague question about user experience and interaction design patterns (not programming) for CRUD web applications.
Let there are few simple entities, e.g. Student, Course, and Lecturer with obvious relations.
As I understand, a CRUD application usually provides a screen per entity to browse entities, update, remove them, and add a new one. The screen may provide also a search box.
The application GUI uses relations to display entity-related information (e.g. courses per student) and navigate from one entity screen to another (e.g. from a Student's course name in the Student screen to the Course description in the Course screen).
Does it make sense ? Are there other GUI patterns for CRUD applications ? What example would you recommend to learn from ?
Sounds logical enough to me. There are some GUI patterns here :
http://www.welie.com/patterns/
http://developer.yahoo.com/ypatterns/
the frameworks like rails generate some scaffolding pages to add /delete/modify the model objects, i'd suggest you to have a look at it .
If I understand you correctly... view models is a concept that allows you to add customized groups of data. Scaffholding etc. would be just a means of quickly generating the data to display on screen. Are you using Asp.net Mvc, Ruby or PHP?
I have another programmer who I'm trying to explain why it is that a UI component should not also be a data-structure.
For instance say that you get a data-structure that contains a record-set from the "database", and you wish to display that record-set in a UI component within your application.
According to this programmer (who will remain nameless, he's young and I'm teaching him...), we should subclass the data-structure into a class that will draw the UI component within our application!!!!!!
And thus according to this logic, the record-set should manage the drawing of the UI.
******Head Desk*****
I know that asking a record-set to draw itself is wrong, because, if you wish to render the same data-structure on more than one type of component on your UI, you are going to have a real mess on your hands; you'll need to extend yet another class for each and every UI component that you render from the base-class of your record-set;
I am well aware of the "cleanliness" of the of the MVC pattern (and by that what I really mean is you don't confuse your data (the Model) with your UI (the view) or the actions that take place on the data (the Controller more or less...okay not really the API should really handle that...and the Controller should just make as few calls to it as it can, telling it which view to render)) But it's certainly alot cleaner than using data-structures to render UI components!
Is there any other advice I could send his way other than the example above? I understand that when you first learn OOP you go through "a stage" where you where just want to extend everything.
Followed by a stage when you think that Design Patterns are the solution every single problem...which isn't entirely correct either...thanks Jeff.
Is there a way that I can gently nudge this kid in the right direction? Do you have any more examples that might help explain my point to him?
Have you heard of Martin Fowler?
Separating User Interface
Code
Anyway, if he wants to go further in that direction of adding render methods to his data controls, have him look at "loose coupling". It's okay to create some generic type of interface that gets him halfway there, but the UI component should take it the rest of the way.
This boils down to functional vs. non-functional responsibilities. What the data structure does and how it's visualized are two completely separate things -- essentially the root of the MVC pattern.
There's also a notion of circular dependencies here. Since the UI must know about the data structures, if you allow the data structures to then depend on the UI, you've got yourself a nice little ball of mud.
Generally on the point of decoupling:
Not only can there be different components of the UI rendering the same data structure. You may even have completely different UIs (Web, Desktop Application, ...) Now of course, you could subclass Person with WebPerson and DesktopPerson (this already sounds wrong, doesn't it? The naming is simply not about the kind of Person - it's about something else).
Each UI could work on different kinds of Persons, e.g. Teacher and Student. So we get WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher and DesktopStudent.
Now let's say, WebPerson defines the method "drawAddressFields()" to draw a web version of the address fields. But since WebTeacher has to derive from Teacher to use the additional data field "salary" (and let's assume single inheritance), it must implement "drawAddressFields()" once again!
So maybe the argument of "this will cause much more work" will help to create some motivation :-)
BTW, it will automatically lead to creating some delegate that implements the code of drawAddressField(), which will then evolve to creating a component that does the drawing separately from the data structure.
Question number three in my quest to properly understand MVC before I implement it:
I have two cases in mind:
The primary application
window needs to launch the
preferences window. (One View
invoking another View.)
The primary Model for an application
needs to access a property
in the preferences Model. (One Model
accessing another Model.)
These questions are related in that they both involve communication across Model-View-Controller triplets, a topic that I haven't found much discussion of in my Googling.
The obvious way to fix this is to wrap everything in a top-level "application" object that handles transactions between Models and allows Controllers to invoke one another's methods. I have seen this implemented, but I'm not convinced its a good idea. I can also see possibilities involving Controllers observing more than one Model and responding to more than one View, but this seems like its going to become very cluttered and difficult to follow.
Suggestions on how best to implement this sort of cross-talk? I feel like its a very obvious question, but I've been unable to find a well-documented solution.
On a broader note, if anyone has a link that shows typical approaches to these sorts of MVC issues, I would love to see it. I haven't had much luck finding solid, non-trivial references. Examples in Python would be lovely, but I'll gladly read anything.
Edit 1:
I see some pretty interesting things being said below and in general no-one seems to have a problem with the approach I've described. It is already almost a lazy form of the FrontController design that Vincent is describing. I certainly don't foresee any problems in implementing that pattern, however, it doesn't seem that anyone has really addressed the question in regards to communication amongst Models. All the answers seem to be addressing communication among objects in a single Model. I'm more interested in maintaining separate Models for separate components of the application, so that I'm not stuffing fifty state properties into a single Model class. Should I be maintaining them as sub-Models instead?
With respect to (1), views don't invoke other views. They invoke controller actions that may result in other views being rendered. In your case, the primary application window contains a user interface element (button, link) that invokes a controller action to display the preferences window.
With respect to (3), model components certainly could be related to one another. This isn't unexpected nor to be avoided, necessarily. For instance your Customer model may have an associated set of Orders. It would be perfectly natural to access the customer's orders via a method in the Customer class.
You might want to take a look at the MVC page on wikipedia for an overview.
You may want to consider looking up the Front Controller design pattern.
The Front Controller pattern defines a single component that is responsible for processing application requests. A front controller centralizes functions such as view selection, security, and templating, and applies them consistently across all pages or views. Consequently, when the behavior of these functions need to change, only a small part of the application needs to be changed: the controller and its helper classes.
This way all requests from the view goes to the FrontController who then decides which specific action (controller) to invoke. Sometimes, it could forward straight to another view as in your first case.
There is no problem with multiple objects in the model talking to each other. In fact that will be very common. The way I see it, all the objects in the Model act like one component to represent the data and operations on the data.
This article might help. And this one.
Model does not mean a single model object. The model is the subset of the entirety of your domain model which is directly related to the controller actions and the views in question.