I'm working on an XmlEditor (similar to XmlNotepad, but using WPF) in which I want to implement personalized menus. I.e. only show the most popular MenuItems on first open, and show all MenuItems when the user explicitly asks for it, either by clicking on the double arrow at the bottom or waiting for a certain amount of time.
I'm specifically looking for feedback on how I should approach this problem: any thoughts are appreciated!
Since you're working on an XmlEditor. It will be a problem for this case. Try using a different editor.
Related
I've been building my Codename One app for the phone screen format so far. There is a separate Form for the main menu, then a second Form with a list of elements, and then a third Form to edit an element selected from the list. Each Form has an overflow menu and various Titlebar command buttons. And each (Extended) Form has a lot of code that implements the functions in the Form and shares variables etc.
However, to use the tablet (iPad) screen estate, I would like to show the main menu on the left of the screen, the list of elements in the middle and the element edit form on the right. Something similar to the screenshot below. This seems to be a common type of layout on tablets and suits my app usage pattern well.
However, I don't see an elegant way of structuring the code to do this. I can't easily combine the list and edit Forms into one Form, and writing a completely new Form just for the tablet format would be a lot of work. I assume others have faced the same challenge and would love to hear how you achieved this.
PS. I know the side menu can be made permanent but that only solves part of the problem, not how to show a list and edit Forms at the same time.
There is no one answer for this but if you look at apps like Codename One Build you would notice they adapt to this form factor.
We usually just use isTablet() to adapt the UI at key points to the different form factor. One element is the permanent side menu which we turn on in the init method using code like this:
if(Display.getInstance().isTablet()) {
Toolbar.setPermanentSideMenu(true);
}
It makes the side menu stay open all the time. Within the code we try to use Container instead of Form. This allows us to package multiple logical pieces into a single UI for the tablet mode.
I want to create a custom GTK Assistant with my own buttons to control moving forward and back pages. I also don't want to end the program so the pages will be constantly looped through.
I haven't been able to find anything on line about this, any help would be appreciated.
Or if there another good way to cycle through different pages/windows with buttons then that would also be appreciated.
At that rate, you might be better off with a GtkStack.
Then set your window to popup or undecorated.
Or for a harder way, you could subclass the whole GtkAssistant and create your own implementation.
You can set your GtkAssistantPageType to GTK_ASSISTANT_PAGE_CUSTOM and create page with your own buttons, but you should manage button's signal.
The other solution is the gtk_assistant_add_action_widget function.
I've got a pretty complex question for any Maya coders...
I want to utilize a drop down menu similar to that of the cmdScrollFieldExecuter's [script editor's] "Show Tooltip Help". It looks like a window that has been appended to the bottom of the inputted text with a feedback of all relative commands or strings.
Does anyone have experience with appending a similar textbox/ window/ menu to typed input, and if so, can you toss me in the right direction?
Note: I am not talking about "optionMenu".
Alternatively, is there a way to get cmdScrollFieldExecuter to reference a different array or set of strings?
A complete port of that won't be possible in vanilla Maya - You'd need to use python and QT because the built-in GUI objects (such as TextField) don't fire any events on keypresses so you won't be able to live-update as the user types.
You can almost fake the visual appearance with a window whose title bar is set to off. Use a formLayout to dock a TextScrollField inside it. You'll need to hack up some way of dismissing it since it won't have a close box -- you could put it on a timer or add an invisible button covering the whole thing which closed the window when clicked
I'm looking to add a 'close' button to my main window's menu. An example can be found in the picture here: http://ifyoucodeittheywill.com/img/crimson-editor.png
(So, there's the normal close button in the window caption area, but, there's also a close button in the window's menu bar -- on the far right).
I'm using basic win32 API's, though an example using MFC would also be fine.
Does anyone know how to do this?
Thanks,
Andrew
These buttons usually come with MDI windows. However I'm pretty sure the depicted application uses either its own, or more probably some advanced third party toolkit. Because, to be honest, what the Windows API and MFC (which is just a classed wrapper around the windows API) give you for GUI programming is unbareably limited.
If you want to design neat UIs steer clear from MFC and better have a look at something like Qt, wxWidgets or the like.
A really simple way of doing this is to use a regular menu item, using AppendMenu, but use the following flags:
MF_BITMAP with a close button bitmap, or MF_OWNERDRAW or to draw it yourself
MF_HELP (aka WM_RIGHTJUSTIFY), a not-very-well documented flag, which will justify the item to the right.
Here's one reference to MF_HELP that I found on msdn - it's actually about using the Win32 API to right-justify a menu item, but using Visual Basic.
MF_HELP (defined in winuser.h) is something of a holdover from Win16 days, back then, the convention was to right-justify the Help menu item, so it would stand apart. It was 'renamed' - an additional #define added with the same value - to WM_RIGHTJUSTIFY around Win95.
Note that bitmap menu items aren't accessible (eg. to users that are relying on a screenreader to read out where they are on the screen); if taking this approach, then at least add a regular 'Close' menu item elsewhere in the menus (eg. under File), so that a user doesn't have to rely on this item, and can also close it through usual means. Also be sure to implement the Ctrl-F4 shortcut, which is what most applications that support multiple documents or tabs use to close the current item.
By all means do not try to create this behaviour yourself. This is functionality that you get "for free" if you are using the MDI architecture of MFC. The close button "next to the menu" as you call it closes the active MDI child window. If you are not using the MDI architecture then there is no point in trying to add a close button there. Can you explain if you are using the MDI architecture?
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.