asked on
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!
Web Development
Last Comment
COBOLdinosaur
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
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!
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
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&
ASKER
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.
Glad I could help a little. :^)
Cd&
Cd&
couldn't resist