Oh, that is a good one. You could make it a modal window. After a while that window (I assume) would get to contain more and more settings. Then all of a sudden, the last setting you added will really make statistics take a very long time. Since the user probably can't foresee that, you wish to confirm that the user have understood the implications. So you need a modal window that ... oops ... you are already in a modal window.
The first thing is to think about as an alternative is to start with direct manipulation. Is there any way you could change the settings right when you are looking at the statistics? Typical example is the familiar "click on column heading to sort table on contents of that column". Consider drag-n-drop objects if that is natural. Second is to have the modal window inline on the page in panel. After all, selected settings and the result in the same window feels better than switching to another window, modal or not and then back. But there may not be room for that. Can you split the settings in groups to inline on several places on the page? Next thing to consider is to have it on another page and here comes another concern in regarding the concept of settings, life cycle. Do all settings have the same settings? Which are per request, per session, per user, per application? Side point? Well, it sure controls presentation since settings with different life cycle should not be presented together. If the selection of statistics is a very separate activity, maybe it should be on separate page before the page that presents the result? Changing settings would be reached by pressing the back button. As you understand, I am guessing here as I have not much to go on. But these are my thoughts. Try direct manipulation, keep selections visible all the time or resort to a separate page. Save modal windows for that yes/no confirmation. You will need it eventually. Kindly, Per On Sat, Jul 4, 2009 at 2:13 PM, Eyal Golan<egola...@gmail.com> wrote: > Per, > I see what you're saying and I have a question. > How would you implement (UI concern) a setting page? > What I mean is, suppose I have a page that shows some statistics. > The statistics can be set by the user. > We implemented a link / button that opens up a modal window to select the > statistics. > How would you do it? > > > Eyal Golan > egola...@gmail.com > > Visit: http://jvdrums.sourceforge.net/ > LinkedIn: http://www.linkedin.com/in/egolan74 > > P Save a tree. Please don't print this e-mail unless it's really necessary > > > On Sat, Jul 4, 2009 at 1:40 PM, Per Lundholm <per.lundh...@gmail.com> wrote: > >> Sorry Martijn but you are so ahead of me that I can't even follow the >> suggestion you make. >> >> However, I just can support you on not using modal windows. We have a >> back office application written in Swing that use modal windows a lot >> and it is just getting worse by each feature added. >> >> Modal windows are really a last resort and should not be used at all, >> if you can avoid it. What I have seen is that they tend to grow in >> functionality over time and suddenly you are faced with the question: >> "should I put a modal window here, oh, I am already in a modal >> window". >> >> (Ranting further), modal windows are primarily for non-expert users >> that need guidance when you wish to be certain that they know the >> implications of what they do. There should be nothing but some >> information and a yes/no question. >> >> Apparently, it seems that the users are pushing you around and >> customer is always right, so what to do? I suggest a step back and >> present a complete new style of interaction that would give users a >> much better flow in the interaction than now. >> >> Thanks for reading. :-) >> >> Kindly, >> Per >> >> On Fri, Jul 3, 2009 at 3:11 PM, Martijn >> Dashorst<martijn.dasho...@gmail.com> wrote: >> > In our apps we (wrongfully IMO) make heavily use of ModalWindow (our >> > users seem to like them). We ran into an issue/race condition where we >> > have shared a model between the calling page and the ModalWindow. We >> > have an autocomplete textfield with an onblur handler attached. This >> > onblur handler is triggered when the modal window is shown resulting >> > in two parallel Ajax requests to the server. This causes the shared >> > model to be attached and detached at the same time, resulting in >> > rather funky behavior. >> > >> > I know that one solution is to not share the model between the >> > ModalWindow and the calling page. But we are looking for alternative >> > (more general) solutions. >> > >> > Options we thought of: >> > - would locking the session for page directed requests implementable >> > (i.e. let resource requests through the barrier, but not both requests >> > to the calling page and the modalwindow page) >> > - would it work to set a client side flag when the ModalWindow is >> > requested, that disables wicket-ajax for the current window to happen >> > (preventing the onblur to trigger Ajax), and is reset when the >> > ModalWindow is rendering in the client? >> > - render the modalwindow page in the current pagemap instead of a new >> > one (would make refresh behavior pretty weird I think) >> > >> > Any other suggestions? >> > >> > Martijn >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
