What do people think about using pretend hyperlinks, in Winforms apps?
Example:
In my example you would click "into" the Organisation record card for Acme Corp Inc or "into" the details of the next appointment.
If we ignore, for the moment, how the user edits the Organisation or adds/removes an appointment, is it a sensible UI in Winforms to use blue & underline to signify click here and i'll take you to a new screen
As in:
TextBox1.Font = New Font("Blah", 8.25!, FontStyle.Underline etc
TextBox1.ForeColor = Color.Blue
Not forgetting:
TextBox1.Cursor = Cursors.Hand
This would be for a reasonably rich application (for example a CRM) where you have a lot of different kinds of screens and the user is navigating between all sorts of records. And you want to show the user that he can navigate between detail views, grids, children, parents, siblings etc.
Pros:
it's familiar to users and it's
obvious, without being obtrusive or
taking up any screen real estate
easy to implement
the often-used alternative (a button
with an icon or even just three dots
[...]) looks a bit old-fashioned,
doesn't work very well in grids, and
takes up space
Cons:
with all the flexibility and control
you have in a Winforms front end, you
should be able to devise a smart ui
without needing to borrow from
browsers (maybe???)
these pseudo links won't behave as
true anchor tags (there won't be any
"visited" [ie. turn me purple if I've
already been in here] or "hover"
behaviour and no open-in-new-tab
features, without a lot of work) ... potentially annoying to users?
detracts from genuine hyperlinks (as
in email addresses etc) - these no
longer stand out as links "out to
the internet" (to the browser, to
email client) ... very minor issue?
Not even browsers work this way. Use a LinkLabel, not a TextBox.
In general, it’s a good idea to use hyperlinks (real or simulated) in thick-client apps for opening forms of additional information. It is helpful to distinguish between a control that merely navigates (a hyperlink) and a command that changes the underlying data (a command button), so the users know what they’re getting into. I don't think most users care (or even know) if a browser is involved or not. Navigating is navigating.
Making an attribute value look and act like a hyperlink like you’ve done is fine except for one thing that is a showstopper for most applications: it precludes any other interaction with the attribute. The user can’t edit or even copy the attribute value since any clicking in the field will launch the new form. Keep in mind that to edit a value, such as to correct a day of the month, the user may be inclined to click in the middle of the field to position the cursor. Even if you’re using a drop-down menu (e.g., to set the organization), you want to allow users to click in the field and select by typing the first few letters of the value they want. If your app has one drill-down-able field that needs to be editable, then for internal consistency none of your fields can use hyperlinks –all drilldown needs to be by some other method.
Also, while hyperlinks are intuitive for navigating, such as drill-down, I’m not so sure they’re good for assigning a field value. There is a difference between getting more information about Acme Corp organization (which is what your Acme Corp link implies) and getting a dialog to pick the organization for John Smith (an assignment function). So if your intent is assignment rather than true drill-down, then links are probably not a good idea. For assignment, the button with the three dots makes a lot of sense. Assignment changes the underlying data, so it should use a command button. It’s a natural extension of the button in a dropdown control. The three-dot button caption minimizes the space used and is associated with dialogs since that’s what they imply in menu and button captions. It might look old-fashioned, but that’s why it works –it’s consistent with past user experiences.
Looks okay to me. The concept of links has anyway already migrated from web to desktop applications. Users should accept this without problems (maybe after first ten minutes playing out with your program).
Also quite popular in enterprise applications.
Maybe consider changing the color, to, maybe brown or green, so that it doesn't immediately imply a native web link.
Also many web applications built with some event-driven frameworks (like ASP.NET WebForms, JSF etc.) heavily use links that do not link anywhere but invoke some server-side processing (basically an event handler). So it's not unusual use.
I don't like it. If I see a link I expect it to open a browser window when clicked. More standard would be to have a little "edit" button/icon next the label. You could get away with having a link-style "(edit)" after the text, that would also look quite normal rather than suggesting a browser is involved.
e.g:
Organisation: | Acme Dustbins (edit) |or
Organisation: | Acme Dustbins| (edit)
Related
I'm using AngularJS 1 with angular-material and ui-router.
Does anyone know what the best practice is for providing a UI for some "new foobar" type thing? In other words, let’s say I have a ui.route putting me at /app/#/foobars/ which shows a list of all the foobars. At the bottom right is a FAB with a big plus sign, which will bring up a new UI something to allow the user to specify how they want their foobar. What is the best practices for this "UI something" that comes up, using Angular?
Should I use an angular-material dialog? (That’s my first inclination, but it seems old-fashioned.)
Do I create a route to /app/#/new-foobar/ and just bring up another UI? (This seems heavy-handed; I don’t want to change the URI, plus I probably want to get back to where I came from after creating the foobar.)
I think that ui-router allows nested states; is this something I would use? But I don't want the new view/component to be embedded in the current view --- I would expect a card or something to somehow "overlay" whatever view is showing.
I wouldn't use nested states for this, as they are intended for things such a master/detail navigation.
The answer to your question is "it depends", as many situations in programming there're always some tradeoffs you must consider. Depending if you're targeting a desktop or a mobile app you'll have more or less space to put these options on the screen. If there're a lot of configuration options you should define a completly different state on wich you layout them and apply this configuration when you come back to the list. If there are not too much of them or you want to keep them visible at the same time as the list, you can go with a SideNav panel that can be locked open depending on the resolution. An alternative I've used sometimes is using a subheader to show some controls, as you can make it "stick" below the header or let it go if you scroll the list. As I told you before is a matter of choices and tradeoffs, and some sense of usability and simplicity towards the final user. There's no silver bullet nor best practice, just follow your intuition. Good luck!
Background: I'm currently developing the client side for a web application, using JavaScript, with jQuery and Backbone.js (these are required by the proponent).
This is an application to visualize and edit data, in a graphical mode (through interactive diagrams representing the data, mainly).
Terminology: Said data is under the format of multiple documents, each containing a list of items.
For the purpose of this question, let the items be composed by an identifier, a textual description, and links to items in other documents. Links should be symmetric (i1 -> i2 exists if and only if i2 -> i1 also exists).
The Current Goal: In this phase, the application should be able to read two documents, display both lists side by side, and then draw lines, connecting the items between both documents, according to their links.
These lines should be editable. In other words, the user should be able to create new links, or remove existing ones (reflecting the changes on the item models).
These documents can be somewhat long, say, some dozens of items (maybe a few hundreds, in a realistic scenario). Of course, the page will be scrollable, to allow the user to see everything.
Also, for user convenience, there should be a slider to scale the view (allowing zoom in/out effects, so the user is given a global and a local view, being the latter more adequate for editing and the former for analysis).
Furthermore, the user should be allowed to hide particular items (useful when an item has many links, creating visual rubbish).
What I've managed to do:
Read data and map it to Backbone models and collections;
Display both documents side by side (Backbone views), with item connections;
Allow interactivity on these connections (drag-and-drop to create lines, click to remove), reflecting changes on Backbone models;
Hide particular items;
Scale effects.
I've achieved this using SVG, after coming across jsPlumb.
The Problem at Hands: The application still needs adjustments (emphasis on the scaling effects). Regardless, I found jsPlumb to be comfortable to work with. However, rendering performance seems to be a little lacking, when using the slider (it's possible that the slider steps are too small, thus firing too many events).
The proponent suggested that I try, instead, Sankey diagrams, to represent this kind of data. They also suggested that I try Sankey by tamc, based on Raphaël.js.
Of course, the visual factor is also contributive.
My question(s): Does this library have a good compatibility with Backbone? Possibly, if I use the resulting SVG elements as Backbone views' elements.
Also, does any of the two have a significant rendering performance advantage over the other?
On a final note, are there any other libraries more adequate to this scenario, worth the time of rewritting the application, that I might suggest to the proponents?
The project is going on, and I ended up using Sankey by tamc, with some extra work of my own, to better adapt it to this particular case.
There's probably a ton of stuff I'm probably missing but recently I was thinking how viable it would be on forms to have users perform an action in the UI such as drag/drop a (for example) paper widget into a box widget (possibly also randomly placed on the page) to represent submission of a form.
The idea behind it being, find some action that a human would more likely be able to perform than a bot. Would this in any way prevent spambots?
(I'm laughing as I type this btw, but I just wanted to see how crazy this idea really seemed)
Sadly I don't think it would help. All that happens when a user clicks, drags and drops a component is that events (like click) get fired. You could just as easily fire those events programmatically if you were a spambot. Nice idea though.
Like most home-made spam prevention methods, it'll work until your site is large enough that a spammer decides to pay some specific attention to your site -- at which point, it'll be broken to pieces. But there's no need to get as fancy as what you're describing. Spam-protection methods as simple as "type 'orange' into this box" or "what is one plus one" will work just as well, as long as your site is only being hit by automated tools.
When designing a form I have the option of putting a close button at the bottom of the form. The form will also have a close form "x" button in the upper right corner of the window as provided by winforms.
Based on the principle of "There should be one and preferably only one obvious way to do it" I was thinking the close button should be removed because of the forms existing default functionality.
What have the rest of you found in your experience that works best for users or has been the standard for UI setup?
I have done a considerable amount of design work, and I can't say I have heard of the principle of, "There should be one way to do [some task]." In fact, I have heard (almost) the opposite: "There should always be one obvious way to do a task, but additional methods could be used to help different user types." An example of this is the ability to hit the "Save" button to save a document. But, you can also do "File > Save" and you can also hit Ctrl + S. Three ways to do the same task.
Also, if you're programming in a Windows environment (as it appears you are), you will automatically get multiple ways of closing a window. The [X], of course, Alt + F4 is typical, you can setup Ctrl + C, etc. I wouldn't particularly put a close button on the bottom of the form unless it flows with the form's input. For example, if you want to [Submit] or [Close] the form - does that make sense? Would it be better to [Submit] or [Cancel]? Think about what your users are doing and how they are using the form.
Here are some guidelines I follow:
If the form is an application (it was launched directly from Windows), it should probably not have a close button. Users expect to be able to close the application by clicking the X in the top-right corner.
If it is a dialog (it was launched from another window within your application) that simply displays information, it should probably have a close button and you can optionally leave the Windows close button as well.
If it is a dialog that allows the user to edit data it should have a Save or Apply button and a Cancel button but no Windows X. The reason is because it is ambiguous what it means. Should it save the data? Cancel it? Display a dialog asking them what they want to do?
In general I do agree that there should be only one way to do something. The reason is that a reasonable user will have to wonder if they do different things (even if they are named the same). Even if the user discovers they do similar things, they may wonder if they are subtly different.
Of course there are exceptions to the rule. For example, most users understand that the file menu, toolbar, and keyboard shortcuts of the same name all point to the same command.
I think that principle applies mostly to coding (and not for every language, think of Perl!), for UI's usually it's good to have different ways to do things... because it allows you to do things faster.
Think about any common operation like cut or paste, you can use the edit menu, the contextual menu, the keyboard shortcut or even the icons in the toolbar. Try to remove any of those ways of doing it in any application and you'll have hordes of users screaming to get it back.
So here the main principle is to not change what the user expects. Another remark: be consistent, though there might be different ways get access to the same functionality, all of them should work in the same way (I'd be very pissed of if copying with the keyboard shortcut did a different thing than copying with the right mouse button XD).
I'm developing a Winforms application which has been running for years with an explorer view (TreeView left, screen right). I means that:
All the screens have an hierarchy organization
All the nodes on TreeView have one and only one screen related.
A screen gets activated when a node on treeview gets selected.
One of the advantages is that the user has an ordered stucture and one of the inconveniencies is that with hundreds of screens the user gets confused.
I see other options: use classical menus, use tabs or a mix of everything.
Any advice for a good way to show a lot of screens to user in a user-friendly way?
Update: I'm changed "hundreds screens" by "a lot of screens". The most important thing is not show all at time but that the user can find what they need easily.
Update2: In this proposal, the user only see one screen at time.
Update3: I'm talking about handling multiple screens not showing multiple screens. No MDI, only one ontime.
I have used other applications similar to this is the past, and the major problem is trying to find the exact screen you want. There are two common solutions to this problem, shortcut codes and favorites menu.
With the shortcut codes, allocate a short code (5 or 6 characters) to each screen. The user then inputs this shortcut code into a text box which will then jump to the correct screen. Users will create their own list of often used codes.
For the favorites menu, allow users the ability to be able to create their own menu list in the structure they want. They will find things easier, if they organize it themselves.
Why do you need to show so many seprate screens at once? Why not just show the screen for the currnetly selected node, why are all needed at once?
If it is all tabular data is is probably too much to be consumed all at once, if it is graphical data, could it not be combined?
There may be a valid reason to show all the data at once or there may not, hard to tell from what is provided in your question. With that said, better to keep it simple than overload the user. MDI apps are never easy to use.
Tabs may work for a small set of items but still is not a good UI for hundreds of items.
If you are only showing one element at a time, out of hundreds possible on the tree nodes, then that is fine. The one screen showing at a time would be contextual to the item selected as the user moves through the nodes. Think of the Outlook approach where what is selected in the left pane is displayed in the right pane in whatever form fits the data being displayed.
Have you considered the Office Ribbon?
The Ribbon gives you a lot of flexibility on how to show and
organize functions and it's highly visual.
Here is a good link about the Ribbon and also here
To use the Ribbon you have to license it from Microsoft. You can do that online.
Providing the user with ketboard shotcuts is usually a good thing too.
I also like to provide the user with an "autocomplete" field on the menu
so that they can can find the function by name (or part of it) and be
able to navigate directly to where they want to go.
I general I find trees to be a bad idea, especially if your "hierarchy" is of a small fixed depth.
If you have a small fixed depth, consider replacing the tree with a list. At the top of the list can be drop-downs for filtering based on the node-level properties. It will use up less screen real-estate because it is vertical-only, with no horizontal component.
Clicking on an item can display it in the view (like currently), but it may be a good idea to allow a user to double-click on more than one item which could launch more windows, or tile with the existing displayed items. (I am assuming that currently, the user only sees a single detailed view at once in any given window.)
Actually, it’s hard to beat a hierarchy for organizing large numbers of items. I wouldn’t favor a classical pulldown menu for vast numbers of windows because it would be even harder to keep track of where you are than in a tree (e.g., a tree lets you look in multiple branches at once). But here’s a few alternatives:
I’m not clear how you ended up with so many windows, but maybe it comes from combinations of classes, views, content, and detail, or maybe it comes from using a task-centered UI structure for something far too complex (I’ve more on that at http://www.zuschlogin.com/?p=3). For complex apps, you want a different primary window for each significant class of data object (e.g., invoices, employees). These are listed on one menu, and typically there’s few enough (15 or less) that it can be single non-cascading pulldown menu. The content of each window is set by a separate menu, perhaps by a menu item that opens a dialog that may include a list box (like an Open dialog) or other controls for querying/searching. The “view” of each window (how the data objects are shown, e.g., table versus form) is set by menu items in the View menu. Details for any given object in a window can be shown in a separate pane within the window in a master-detail relation, essentially turning you data objects into a menu for details. A single window can have multiple detail panes for the user to open and close to select the specific detail to show. Tabs may also be used within a single pane to fit subdivisions of content.
You say it’s not important to show all window options at once, but often showing all options at once makes it easiest for users to find what they need. Maybe you need a “home” window that lists all the other windows in organized, labeled, and separated categories. This is will be easier to use than the tree if your users select a window then stick with it for most of the session. Your tree is better if there's frequently selection of windows throughout the session, owing to the overhead of getting to the home window. If all windows/options don’t fit on a single home window, then show only selected common windows for each category on the home window and provide a button or link to show an exhaustive list.
If you’re talking 100’s of windows, maybe you should have Search, perhaps in addition to a menu-based browse approach to getting to a window.
In any case, providing easy access to the few most commonly used windows is a good idea. Such windows can be explicitly selected by the designer, based on user research, or selected by the the user (favorites), but it also typically works well to make it automatic with an algorithm that uses some combination of frequency and recency of use.