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 / jhung at ocad.ca <jhung.utoronto at gmail.com>
IDRC - Interaction Designer / Researcher
Fax: (416) 977-9844
On Tue, Oct 5, 2010 at 1:50 PM, James William Yoon <jyoon at ocad.ca> 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 <jhung at ocad.ca> 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 / jhung at ocad.ca> > IDRC - Interaction Designer / Researcher
> > Fax: (416) 977-9844
> >
> >
> >
> > On Tue, Oct 5, 2010 at 1:29 PM, Justin Obara <obara.justin at gmail.com>
> 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 / jhung at ocad.ca> >> IDRC - Interaction Designer / Researcher
> >> Fax: (416) 977-9844
> >>
> >> <Reorderer.png>_______________________________________________________
> >> fluid-work mailing list - fluid-work at fluidproject.org> >> To unsubscribe, change settings or access archives,
> >> see http://fluidproject.org/mailman/listinfo/fluid-work> >>
> >
> >
> > _______________________________________________________
> > fluid-work mailing list - fluid-work at fluidproject.org> > To unsubscribe, change settings or access archives,
> > see http://fluidproject.org/mailman/listinfo/fluid-work> >
> >
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org> To unsubscribe, change settings or access archives,
> see http://fluidproject.org/mailman/listinfo/fluid-work>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://fluidproject.org/pipermail/fluid-work/attachments/20101005/93462700/attachment.html>