I guess it really depends on the content. As long as it is content that not interactive, then I think it will be okay. Otherwise users may be confused as to what is being shown to them (as with the uPortal demo) or file bugs against components / UI elements that isn't part of the primary demonstration.
I think it's okay to abstract a little for these demos. If they want to see it functioning in a more complex case, we can put a link to the uPortal example? - Jonathan. --- Jonathan Hung / [email protected] <[email protected]> IDRC - Interaction Designer / Researcher Fax: (416) 977-9844 On Tue, Oct 5, 2010 at 1:50 PM, James William Yoon <[email protected]> wrote: > Hi Justin and Jon, > > Justin Obara wrote: > >> This is a nice improvement on the existing demo. I'm not sure if in the > >> future we'll want to have actual content in the movable items, or if > that > >> will just make things too confusing for the demo. > > Jonathan Hung wrote: > > I don't think we should have actual content inside the content boxes > because > > it may end up confusing the user. However, I think we should try to use > > different sized content boxes just to show how the code handles that. > > Two things to consider here: > a) If it's confusing for users to have content inside content boxes, I > think we may have a bigger problem. > b) IIRC, part of the reason for refreshing the demos was to put the > components into a better context--something more than simply showing > the component and something less than having a full integration demo. > In this sense, I think "real" content might be something to consider. > > Thoughts? > > Cheers, > James > > On Tue, Oct 5, 2010 at 1:39 PM, Jonathan Hung <[email protected]> wrote: > > I don't think we should have actual content inside the content boxes > because > > it may end up confusing the user. However, I think we should try to use > > different sized content boxes just to show how the code handles that. > > Re: Small Drag Bar. > > The drag bar is cosmetic and the user can drag using the entire content > box. > > There is a hover / focus style for the entire content box (not shown in > this > > wireframe) and the mouse cursor changes to a grabber to indicate the > content > > can be moved. > > Thanks for the comments! > > --- > > Jonathan Hung / [email protected] > > IDRC - Interaction Designer / Researcher > > Fax: (416) 977-9844 > > > > > > > > On Tue, Oct 5, 2010 at 1:29 PM, Justin Obara <[email protected]> > wrote: > >> > >> Hi Jonathan, > >> This is a nice improvement on the existing demo. I'm not sure if in the > >> future we'll want to have actual content in the movable items, or if > that > >> will just make things too confusing for the demo. > >> I've made some more comments below. > >> Thanks > >> Justin > >> On 2010-10-05, at 12:36 PM, Jonathan Hung wrote: > >> > >> Hi everyone. > >> Attached is an illustration of a proposed update to the Layout Reorderer > >> demo. > >> The notable changes are: > >> - the use of a locked icon to indicate locked content. > >> - addition of instructions and description of usage. > >> - a top "drag bar" to movable content. > >> > >> Is this "drag bar" just to indicate that the element is draggable or > will > >> this be used as the handle for performing the drag. If it is the latter, > I > >> think it may be a bit small. > >> > >> - an asymmetrical layout bearing resemblance to a website with 2 > sidebars > >> and a main content area. > >> Accessibility question: > >> - How is this demo accessible to screen readers? I feel that the > feedback > >> will need to be descriptive in order to convey the proper ordering and > >> relationships of objects as they are moved between columns. > >> > >> We have jiras on bug parade for this. I don't think they'll be easy > >> though, but we are going to try to have it done for 1.3. > >> > >> Questions: > >> 1. Do you think locked content should have a more distinctive > appearance? > >> 2. What is your opinion of using a lock icon versus having the words > >> "Locked"? > >> > >> Implementation question: > >> 3. The lock icons in the content area will be implemented as background > >> images as to not interfere with ATs (in effect be invisible to screen > >> readers). However, the lock icon in the instructions will be "seen" by > ATs. > >> It is potentially confusing that the instructions reference a lock > image, > >> but the rest of the demo does not as far as the AT is concerned. How > should > >> this be handled? > >> > >> Not totally sure, but I think as long as the locked portlets are > >> identified as such, to AT users, then the locked icon is just styling. > Your > >> instructions don't seem to necessarily refer to the lock icon, so I > think it > >> is okay. > >> > >> > >> Thoughts on the overall design and comments to the above questions are > >> welcome! > >> - Jonathan. > >> --- > >> Jonathan Hung / [email protected] > >> IDRC - Interaction Designer / Researcher > >> Fax: (416) 977-9844 > >> > >> <Reorderer.png>_______________________________________________________ > >> fluid-work mailing list - [email protected] > >> To unsubscribe, change settings or access archives, > >> see http://fluidproject.org/mailman/listinfo/fluid-work > >> > > > > > > _______________________________________________________ > > fluid-work mailing list - [email protected] > > To unsubscribe, change settings or access archives, > > see http://fluidproject.org/mailman/listinfo/fluid-work > > > > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work >
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
