*Therefore the columns need to be re-sizable, minimisable, etc* Behavior could be heavily constrained for some views. My desire is to avoid as much dragging/rearranging as possible on the user's part. For example, gChat boxes inside Gmail look like windows-- but there's no resizing or moving available (there is minimising and popping out of the screen).
There are cross-browser challenges to be sure, for instance when a user resizes the browser window. *Iframes* In the column view, IFrames and gadgets should not load. This is part of the appeal: you can browse several Waves' content and check what's been updated without loading all that junk. As I've alluded to with the Yes/No/Maybe placeholders, it would be nice if the column view could display a summary of a gadget's current state. *I too agree that inline replies can make a wave horrible.* Inline replies will eventually be one of Wave's very attractive features. They could be used for footnotes, marginalia, corrections, and other annotations. But on Gwave, they seem to rend posts apart mid-thought. I don't believe they belong in the normal flow of threaded conversation. *On jQuery and JavaScript libraries:*w could display a summary of a gadget's current state. I'm using a small subset of jQuery for this demo, but that could easily be replaced by standalone javascript once we've narrowed down the desired functionality. Thanks for the feedback, I hope to have new views to post sometime this week. On Fri, Dec 3, 2010 at 8:37 PM, Chris Harvey <[email protected]> wrote: > I had looked at Miller columns before but not seriously thought the > approach would be useful until I saw Chang's excellent Tensor UI demo. > > I have created a working prototype UI based on Miller columns for iotaWave. > These are my thoughts thus far: > > 1. For our purposes, we need N columns; where N is variable depending on > use-case but could be up to 8 columns. Therefore the columns need to be > re-sizable, minimisable, etc, This causes *a lot* of cross-browser > development fun (in particular relating to what Firefox does to iFrame > (gadget) content. Chrome is much better. ... haven't started on the various > IE flavours yet). > > 2. Multiple columns (with divs for resize, minimise, maximise, title, grab > bars, etc.) is a *real* pain in cross-browser CSS. HTML tables help greatly > to manage columns and their content. > > 3. Sometimes columns need to be visible on the screen at the same time, > sometimes scrolling right works ok. (This is design/usability-related but > has the expected knock-on effects to coding). > > 4. Populating the columns with DOM operations (lower-level control but more > code) or innerHTML (simpler but faster) has knock-on implications for > aforementioned minimising, etc. > > I've spent 10 days working to create a useable (iotaWave-integrated) UI. > Two days on the core development. Eight days on cross-browser issues. > Beware. > > I too agree that inline replies can make a wave horrible. We have been > holding-off implementing inline replies for that reason (and the fact that > the average user has too many editing options to mentally comprehend), I > follow your thoughts/ideas for their extraction with interest. > > -- > Chris > iotawave.org > Singapore > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
