On 07/29/2013 07:36 AM, Brian Wolf wrote: > Perhaps the "common denominator" of an area of the application. For > example, in AR lots of functionality surrounds the customer; in AP, > the vendor. There's probably much overlap in selecting an entity, > viewing (perhaps a dashboard) basic information about it, and > performing operations on that entity (eg, receiving a payment). It > might be effective to have a one-page for a specific area of the > application. > On 07/29/2013 09:49 AM, Chris Travers wrote: > >> One thing I would ask is that if we go with a multi-page design, what >> are the aspects of one-page design that we should be looking into >> incorporating? >> >
I think the natural place to start is with overview lists -> detail views. In many cases, being able to see multiple transactions at once is very helpful. Having some panes for viewing/editing data, possibly some modal dialogs for data entry, and similar can be really helpful. I've got a pretty sizeable single-page app we use for much of our business, but it keeps the page paradigm -- pages get loaded into tabs which may be opened or closed. We've pretty much ignored the challenges Brian pointed out with state across refreshes -- as an internal app, we just take you back to a launch tab on refresh, you have to open up whatever you need. I did have a browser history manager partially implemented that would re-open tabs you had closed when you hit the back button -- but it wasn't high enough value for us to get fully working. In any case, converting the multiple pages into more usable standalone pages is clearly the next step. I think it's eventually worth experimenting with single-page apps, but not necessarily immediately, and make sure whatever UI we come up with ends up with a consensus before making it official -- probably try out a few different paradigms and see what we all like. Whatever we do, I think the app should be able to fall back to multiple pages, e.g. with js off, or with a lighter UI version for mobile, or whatever. Brian mentioned earlier a drop-down menu instead of a tree -- I was planning to just replace the current tree with a Dojo tree, which does use a cookie to remember previous state of expand/collapse. This seems like a really good place to start our experiments -- once we have the menu in a store, it's pretty trivial to switch between a menu bar and a tree widget. So is there any further objection to adding Dojo to the current trunk? The version I've put in my git repo does currently weigh in at 62M -- though currently it's adding around 140K to the page loads I've set up so far... Happy to see a few other developers on the list with Dojo experience! Cheers, John Locke http://www.freelock.com ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
