Learn the top ten threats that are present in modern web-application development and how to protect your business from them.
Reduce browser header bars to focus attention, or counter-productive?
This is a general question about web design. I'm reworking an asp.net application using VS2010 (tested on IE8 mostly) for doing real-time collaboration using drag and drop process diagrams with context menus (so it has lots of detailed javascript routines).
I'm down to tweaking usability and expanding browser compatibility. The app has a "Main Page" where all the work is done. Originally I designed it so that this page would open with javascript window.open, and have no menubars, toolbars, etc, at the top, and to be maximum size with no scrollbars and not resizable. My thinking was that this was not a standard web page where the user would consume content, click on links, etc. This was a single page where they would stay and do work, and so I wanted to maximize available space, remove distraction, and prevent size changes that would hide controls.
I appreciate the guideline that if this were a regular web page the users would not like having restrictions on the use of the headers, etc. But for a single purpose page, I still don't think the headers and such are going to be useful, and if people want to multi-task they can open another browser instance.
But now I'm trying to get it to work with Chrome and FireFox, which makes the "windows.open" command trickier, and maybe the user would need to adjust browser controls in some way to get the app to work the way I want it to, and thinking about whether it could be used on tablets so I might need scrollbars.
What I'm hoping for is any input that would help me think about the balance between 1) ease of development for multiple browsers, 2) the "stay focused" approach of no unneeded page header bars, 3) simplicity of not scrolling (which affects the drag and drop) and 4) general hassles of having a non-standard page (no scrollbars, headers, etc.).
Any links, thoughts or suggestions on this would be appreciated.
Thanks!
I'm down to tweaking usability and expanding browser compatibility. The app has a "Main Page" where all the work is done. Originally I designed it so that this page would open with javascript window.open, and have no menubars, toolbars, etc, at the top, and to be maximum size with no scrollbars and not resizable. My thinking was that this was not a standard web page where the user would consume content, click on links, etc. This was a single page where they would stay and do work, and so I wanted to maximize available space, remove distraction, and prevent size changes that would hide controls.
I appreciate the guideline that if this were a regular web page the users would not like having restrictions on the use of the headers, etc. But for a single purpose page, I still don't think the headers and such are going to be useful, and if people want to multi-task they can open another browser instance.
But now I'm trying to get it to work with Chrome and FireFox, which makes the "windows.open" command trickier, and maybe the user would need to adjust browser controls in some way to get the app to work the way I want it to, and thinking about whether it could be used on tablets so I might need scrollbars.
What I'm hoping for is any input that would help me think about the balance between 1) ease of development for multiple browsers, 2) the "stay focused" approach of no unneeded page header bars, 3) simplicity of not scrolling (which affects the drag and drop) and 4) general hassles of having a non-standard page (no scrollbars, headers, etc.).
Any links, thoughts or suggestions on this would be appreciated.
Thanks!
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Let me give you a little advice from a long career in which I had to develop a lot of user interfaces. It does not matter what you thinks is good.
What have the users asked for? Not mangers, or analyst or teckies. The only thing that matters in any user interface is making the users comfortable based on what they want. The best design in the world is worthless if the users don't like it and start looking for workarounds.
That said from a technical standpoint you are creating a Frankenstein monster. When you try to play with browser controls you are guaranteed to have cross browser issues; future incompatibilities, and an open invitation to hacking.
Rather than trying to make all browsers work the same you might better off trying to use the unique capabilities of each browser to enhance the user experience.
Cd&
What have the users asked for? Not mangers, or analyst or teckies. The only thing that matters in any user interface is making the users comfortable based on what they want. The best design in the world is worthless if the users don't like it and start looking for workarounds.
That said from a technical standpoint you are creating a Frankenstein monster. When you try to play with browser controls you are guaranteed to have cross browser issues; future incompatibilities, and an open invitation to hacking.
Rather than trying to make all browsers work the same you might better off trying to use the unique capabilities of each browser to enhance the user experience.
Cd&
partially agree with Cd's comment ...
looking from a security point of view, I'd only use such an application (browser with no controls) if the system is not connected anyhow to any other system and never will be
also keep in mind that HTML was designed (back last century) to give the user control about the final view of the content and not forcing her to use what a geeky developer had in mind (think about disabled users also!)
if you want to force the user to use what you like, build your own app and hand it over, but please don't try to break (mainly) well designed rules, that's why chrome and FF don't allow kiosk mode anymore
just my 2 pence ...
looking from a security point of view, I'd only use such an application (browser with no controls) if the system is not connected anyhow to any other system and never will be
also keep in mind that HTML was designed (back last century) to give the user control about the final view of the content and not forcing her to use what a geeky developer had in mind (think about disabled users also!)
if you want to force the user to use what you like, build your own app and hand it over, but please don't try to break (mainly) well designed rules, that's why chrome and FF don't allow kiosk mode anymore
just my 2 pence ...
This has been tried many many many times, and always always always failed. Users ABHOR to have their browsers messed with. Period.
It sounds like your application is not a web application, and so maybe should not be built as such.
It sounds like your application is not a web application, and so maybe should not be built as such.
I agree with the others. I think that making the browser act different will be a constant distraction instead of providing focus. The familiar look of the browser will allow the user to generally ignore it since it is what they are expecting.
If it isn't really a web app for a browser, then you should write it as a Windows app. Depending on what you are doing, you might be able to write it as an HTA HTML Application which doesn't have to look like a browser but uses the IE HTML engine for display.
http://en.wikipedia.org/wiki/HTML_Application
http://msdn.microsoft.com/en-us/library/ms536496%28v=vs.85%29.aspx
If it isn't really a web app for a browser, then you should write it as a Windows app. Depending on what you are doing, you might be able to write it as an HTA HTML Application which doesn't have to look like a browser but uses the IE HTML engine for display.
http://en.wikipedia.org/wiki/HTML_Application
http://msdn.microsoft.com/en-us/library/ms536496%28v=vs.85%29.aspx
...UPS decided that it would be easier to deliver packages to your home if it wasn't for that fugly fence you had.. so now every time they come to your house, they tear down your fence. And as an added bonus, w/o that fence, it makes for a much better photo-op for their marketing! Yay!
couldn't resist
couldn't resist
Thanks for the inputs. This is effectively solved. I understand I need to give up attempting to control the browser appearance. (Must...resist...residual.
However, I figured I'd go for broke and see if there is any additional input, or at least explain this to myself.
1) I concur on the importance of user feedback. Issue: no user base yet. The app is an attempt to cram an existing method for flip chart-based group process improvement sessions into 1024x768, so it's fairly constrained about what it can/should/must do. A planned marketing program (book, web site, community) will have to succeed if and before the app even gets to beta. I've got a few reviewers in the mean time.
2) The comment on "cross browser issues; future incompatibilities, and an open invitation to hacking" was a major selling point. The "incompatibilities" reminded me of tablets, android, linux, Macs, etc.
3) The note about disabled users was another selling point.
4) The application will not be connected to any other application in early releases. It downloads and uploads xml for save/restore.
5) "tried many, many, many times" helped.
6) I thought a good bit about making it an app versus a page when I first started on it. (Back story: the primary development was in 2006 and 2007; clearly a lot has changed since then). The app is envisioned to run something like Webex, with scheduled sessions (though if it works at all it will be more likely run at least initially *inside* Webex sessions). Participants will get an invitation email with a user id and a password, and be able to log in via whatever browser they choose. In 2005 I figured people might want to run it from Macs. Now maybe from Android tablets, Linux boxes, and next year who knows what. The inputs are all only short text phrases, so that may be possible.
So, having written that all out, I'm much more settled on not messing with the browser. Which also, helpfully, further reinforces my otherwise tentative decision to convert the javascript to JQuery. Ack!
Thanks again, big help!
However, I figured I'd go for broke and see if there is any additional input, or at least explain this to myself.
1) I concur on the importance of user feedback. Issue: no user base yet. The app is an attempt to cram an existing method for flip chart-based group process improvement sessions into 1024x768, so it's fairly constrained about what it can/should/must do. A planned marketing program (book, web site, community) will have to succeed if and before the app even gets to beta. I've got a few reviewers in the mean time.
2) The comment on "cross browser issues; future incompatibilities, and an open invitation to hacking" was a major selling point. The "incompatibilities" reminded me of tablets, android, linux, Macs, etc.
3) The note about disabled users was another selling point.
4) The application will not be connected to any other application in early releases. It downloads and uploads xml for save/restore.
5) "tried many, many, many times" helped.
6) I thought a good bit about making it an app versus a page when I first started on it. (Back story: the primary development was in 2006 and 2007; clearly a lot has changed since then). The app is envisioned to run something like Webex, with scheduled sessions (though if it works at all it will be more likely run at least initially *inside* Webex sessions). Participants will get an invitation email with a user id and a password, and be able to log in via whatever browser they choose. In 2005 I figured people might want to run it from Macs. Now maybe from Android tablets, Linux boxes, and next year who knows what. The inputs are all only short text phrases, so that may be possible.
So, having written that all out, I'm much more settled on not messing with the browser. Which also, helpfully, further reinforces my otherwise tentative decision to convert the javascript to JQuery. Ack!
Thanks again, big help!
cram an existing method for flip chart-based group process improvement sessions into 1024x768,
Why limit yourself to trying to adapt an old design. When that app was new, browsers were far less dynamic and flexible then the modern fire-breathing engines.
You can do very dynamic presentation with overlays, stack/unstack, show/hide, and panels that maximize space utilization. it is what makes it possible to do some pretty complex stuff on tablets and tiny phone screens.
HTML5 and CSS3 provide the browser with meta data that results in the creation of a document object that is a thing of beauty, and the whole thing can be manipulated to great effect off of the extended event set with very little scripting. You do not need bloated jquery libraries for the kind of simple functions and object references required for space management.
Cd&
Cd&: Thanks for the input. Re the comment on JQuery, I'm glad you said that because I didn't have the heart for that conversion, so I'm going to put that off until I run into some major browser compatibility issues (the latest one was innerText vs textContent, but that wasn't too hard to build get/set functions for).
The main reasons I'm focused on the original design are 1) about 4000 hours of existing investment (had to learn asp.net from an Access VBA technical knowledge base) 2) much less current availability (sigh) 3) there's a limited development time window, 4) the original design has resizable panels (well, resizeable height divs, two sides, three per side), and 5) I have this idea that the "cognitive effect" of using the software will be created with as much information visible at one time as possible (we used to run the group sessions with up to seven flip charts).
On the hand, I've recently decided to "undock" the "help" panel, so people can do what they want with it. And I've been wondering if there was any need to lock in place the "operator control" panel and the "activity selection" panel. Which bring us to the "discussion" panel, which is just a little chat window, which could also float. And finally, I'll think about whether people could just flip back and forth between the diagram and comments panels, or optionally click something to line them up side by side as they are now.
Plus I've been feeling uneasy about an architecture that denied mobile use, which was just coming into view in 2006. I may not have the time to implement mobile, however, I may be able to re-architect the app so that if it gets any traction on PCs I could get it over to mobile later.
So, that was good input! I'll do some research on moving little panels around a page. The current panel resizing isn't very good code anyway, and I'll have to rework it to allow for the shorter browser space and scrollbars anyway, so what the heck. I wouldn't be doing this if I weren't a code addict, and better designs definitely provide more of whatever that attraction is.
Grazie!
The main reasons I'm focused on the original design are 1) about 4000 hours of existing investment (had to learn asp.net from an Access VBA technical knowledge base) 2) much less current availability (sigh) 3) there's a limited development time window, 4) the original design has resizable panels (well, resizeable height divs, two sides, three per side), and 5) I have this idea that the "cognitive effect" of using the software will be created with as much information visible at one time as possible (we used to run the group sessions with up to seven flip charts).
On the hand, I've recently decided to "undock" the "help" panel, so people can do what they want with it. And I've been wondering if there was any need to lock in place the "operator control" panel and the "activity selection" panel. Which bring us to the "discussion" panel, which is just a little chat window, which could also float. And finally, I'll think about whether people could just flip back and forth between the diagram and comments panels, or optionally click something to line them up side by side as they are now.
Plus I've been feeling uneasy about an architecture that denied mobile use, which was just coming into view in 2006. I may not have the time to implement mobile, however, I may be able to re-architect the app so that if it gets any traction on PCs I could get it over to mobile later.
So, that was good input! I'll do some research on moving little panels around a page. The current panel resizing isn't very good code anyway, and I'll have to rework it to allow for the shorter browser space and scrollbars anyway, so what the heck. I wouldn't be doing this if I weren't a code addict, and better designs definitely provide more of whatever that attraction is.
Grazie!
This is not exactly what you are doing, but this bit of dynamic page management might give you some ideas. The scripting is dead simple; maybe even a little old-fashioned but I can use those simple functions to move and place elements where I want them off of any event.
It is part of an article about dynamics across 4 dimensions
Cd&
It is part of an article about dynamics across 4 dimensions
Cd&
Good tip, good site; got it bookmarked, thanks.
I've built a set of functions based on mousedown, mouseup that that check for click, double click and drag, and I've implemented drag and drop using graphic clones that works in IE, Chrome and FF, and includes with scroll drag. So I think I can apply those functions to moving and resizing panels relatively easily. Again I appreciate the encouragement to make the design more flexible.
I've built a set of functions based on mousedown, mouseup that that check for click, double click and drag, and I've implemented drag and drop using graphic clones that works in IE, Chrome and FF, and includes with scroll drag. So I think I can apply those functions to moving and resizing panels relatively easily. Again I appreciate the encouragement to make the design more flexible.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial