The fact that the application will be deployed in an environment where the browser/platform are known is not a good reason to diverge from the usual ways that navigation is provided in browsers.
One reason that web browsers work as a vehicle for delivering internal applications is that users are familiar with the basic way that they operate. A tredeoff for this "out-of-the-box" interface is a limited set of interface controls, when compared to desktop applications. That hasn't stopped designers and coders worldwide from building some pretty impressive applications on the world wide web. Remember that most of the people who will be using your new application will be familiar with the way the same browser normally works outside your controlled environment. Introducing a different way to use a familiar tool will cause confusion. Even after your users become familiar with the new way of doing things, a slight confusion will always be present as long as the world wide web at large does things slightly differently from how your application does them. Consider not using a standard web browser as a delivery vehicle.. On Mon, 11 Aug 2008 06:23:21, Jennifer Cummings <[EMAIL PROTECTED]> wrote: > Thanks for all of your feedback. You've made some key points, and > it's good to have this input. Just some further information for > discussion: > > My team (UE) originally recommended using dynamic tabs within the > page...similar to how Yahoo! Mail opens the inbox and all messages > into separate tabs. The browser tab alternative is what the technical > team would prefer to do, because our records are much more complex > than mail messages and they are leary of the framework they would > have to build. > > Some of my concerns are: If you code links to open into a new tab, > are you likely to have some of the same user confusion that we see > when links are opened into a new browser window? > > How weird is it that the second level navigation (the tabs) will be > visually placed above the first level navigation (a menu bar)? > > What is the risk of coding not to Web standards in this way? > > What is the risk of using a solution that I, at least, have never > seen anyone else use? > > As to testing, the tech team did prototype the idea and showed it to > users, who liked it because it doesn't take up much space. However, > there has been no usability testing. There isn't really time to test > well enough to reveal whether the tab idea will be confusing or > problematic, since that would require mocking up enough pages for > users to open one or more records and complete at least one task. (I > have to have a recommendation by tomorrow.) > > So, I'm relying on expert opinion. If anyone has any further > thoughts, I'd love to hear them. And, I appreciate the input > you've all given me so far. > > > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > Posted from the new ixda.org > http://www.ixda.org/discuss?post=31904 > > > ________________________________________________________________ > Welcome to the Interaction Design Association (IxDA)! > To post to this list ....... [EMAIL PROTECTED] > Unsubscribe ................ http://www.ixda.org/unsubscribe > List Guidelines ............ http://www.ixda.org/guidelines > List Help .................. http://www.ixda.org/help > -- Sent from Gmail for mobile | mobile.google.com _____________________________________ Darlene Pike / Pike Design Web coding for technically challenged visionaries™ web: www.PikeDesign.com ph: 973-600-7113 ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
