I have a really simple question: in what occassion should I use the hamburger menu on desktop websites. Or is there no situation that this is usefull? I am really curious about your opions about that!
(Design perspective) No situation. With a desktop application you should have ample space to provide some type of visually appealing menu that can accordion or swipe off, spin and disappear the possibilities are endless. However, for mobile this is an icon that is easily understood and takes up little space. A user automatically knows AH there is the menu. For a generic menu not just the button Apple is notorious for providing a long list of things to swipe on.
Related
new to codename one, and I'm looking to build a fairly robust app. I've read a lot of codename one documentation and have looked through many of the demos on git. My question is, what is the best way to architect the application?
Here are my basic requirements:
Splash screen
Lock screen (enabled/disabled by user)
Sliding (hamburger) menu
Contents of sliding menu will change based on current 'form'
Application settings
Based on this short list of requirements, would it better to make each different screen a form, and the sliding menu for each a different 'instance', or make a main form that contains the sliding menu (and just change contents of menu based on current screen) and make each different screen a component instead of a form?
Also, I was considering coding it by hand, and not using the gui builder.
Thank you.
Greg
I would go with separate forms mostly because of the hassle of updating the side menu for every selection you make. This would also make the general design more flexible.
Kinda new to Silverlight and have some experience with WPF but I'm doing a project with a group for a class making a game for WP7. I am currently in charge of the menu system for the game and I had a few ideas for "flashy" menu transitions. I got some going for the main menu but I wanted to do something cool for the options submenu.
Anyway my idea is to either fashion an expander or to have sort of a variation of a dialog box. But the way I envisioned it would be in either case the menu items blur but are still visible while the expanded menu is displayed or while the dialog is active. If I'm being confusing sorry :) but think of Windows 7 glass effect on the menu while other options are available.
What I'm getting at is I want to give this a shot but I have no idea how I would go about doing something like this. Could anyone point me in the right direction or outline some key steps for me to build off?
I tried finding something like this on Google but no such luck.
I would recommend taking a look at the many items available in the Education Catalog over on the AppHub - http://create.msdn.com/en-US/education/catalog/?contenttype=0&devarea=65&platform=54&sort=1
So I'm porting an application from WPF to Silverlight and I have realized that there is no standard Menu control.
So I look around and find some third-party controls that emulate the menu control, like this one at codeplex:
alt text http://www.deviantsart.com/upload/1adt6b3.png
But then I decided to take advantage of this situation and think of some new metaphors besides the standard menu we have been using since Windows 3.0, e.g. I like the following enabled/disabled buttons for a small number of choices, which also work well as a vertical stack, and will try to integrate a drop-down button idea to allow it to hold the number of nested choices that a standard menu control could hold:
alt text http://www.deviantsart.com/upload/1bbtg9l.png
What is the best application navigation menu metaphor you have seen or used in a Silverlight line-of-business application?
How about the Office Ribbon?
http://timheuer.com/blog/archive/2009/01/20/ribbon-control-for-silverlight.aspx
http://www.divelements.co.uk/net/controls/sandribbonsl/
http://msdn.microsoft.com/en-us/office/aa973809.aspx
Personally, I like the style of Apple's CoverFlow.
You can load various screens in each of the CoverFlow "panels", show the Active panel in the center, and tightly pack the other panels to the left and right.
You gain the ability to allow the user to see their other panels while working on the active one...and you can add a little flair when the user switches between the panels.
I have a winforms application that doesn't have a shared set of tools that I can provide on a toolbar. But I want to have a toolbar, so I was planning on using that space to provide quick links to the most popular portions of the product. I will eventually add knowledge to the product to know which screens the current user favors and provide those as quick links on the toolbar. But is this a reasonable use of a toolbar for a desktop product, from a design and usability point of view?
Do not automatically add knowledge about what a user prefers to generate a toolbar. Having a dynamically generated toolbar is confusing for users. It's fine if your configuration bar makes suggestions dynamically (i.e. suggesting buttons), but changing the layout itself is evil.
I think a toolbar makes a good aesthetic, but if you merely want to seperate parts of the app then a Tab bar makes more sense for usability.
With the advent of tabbed browsing, every user understands the tab concept.
Sure. Firefox has something similar in their 'Bookmarks Toolbar'.
Peachtree Accounting also has a toolbar like this, as do many others.
Tabbing is OK as long as there aren't too many.
Would be real good if the user could personalize the toolbar themselves. Sometimes I don't only want places I frequent, but screens that I use occasionally that are hard to find through menus or whatnot.
To me, this looks like a job for a menu with a MRU list, or support 'Add to Favorites'.
ToolStrip with MenuStrip or RibbonBar?
It combines both of the controls. It also have a TabPages navigation, contextual tabs, etc. However the RibbonBar is a very complex control and when you open a new document in for example Word2007 the half of the screen you see a Ribbon Bar. It is not cool. When you have toolStrips you can layout them to Top, Bottom, Left, Right and have more control of the UI look. We can also hide the toolstrips which we do not want to see and they no longer take any screen space.
Ribbon Bar
It boils down to what you're trying to navigate and how complex do you want the Navigation to work.
I prefer to use simple existing applications to base my programs.
Thus for the most part I use either the MenuStrip + X ToolStrips or just a simple ToolStrip if a menu is more involved than is required to get a task done.
But I would have to guess that many people like the Ribbon Bar since it combines the functionality of both Menu and ToolStrips into one control.
Ribbons look more modern, and will help to give you application a modern and current look.
As for usability, I've preferred the experience, as long as you are unfamiliar with the app.
For apps where you are used to a menubar, it's a difficult change, but for new apps or new users it's a good improvement.