I agree John. My fear was that we could be slipping into a technology
focus, and sticking with a model that we simply inherited. I am
suggesting that we take a look at the columnar model of presentation,
and decide if it really is user-focused, and that it does add benefit to
both the viewing and customizing of the page. If we convince ourselves
that it does, based on good evidence, and/or well-established design
principles, we should continue to work with it. If not, then we should
consider the pros and cons of the alternatives.
A lot of work was done in the early days of windowing system on just
this sort of problem. We had tiling competing with stacking, and all
sorts of dashboard approaches. If we think of portlet windows like we
do desktop windows, what should be the organizing constraints, and what
should be free for customization?
Paul
John Norman wrote:
I believe we have slipped into technology focus here rather than user
focus (apologies if I am wrong). A portal page is a place where
columns make sense (to me). I think of it like a traditional (e.g. NY
Times) newspaper. Many years have gone into developing presentations
that get a lot of information onto a page in a readable way. Columns
help here. In other situations, the page layout may want to be more
flexible as Paul suggests, e.g. placing functional fragments (a
discussion thread, or an assignment in education examples) into a page
of text or text and images. The placing of images in a word document
is a simple and well known example. In this case, there are other
considerations such as how the text flows around the dropped object.
Is this still the same process and should it use the same technology
(code)? I suspect there would be value in reusing code but it might
really be a different design pattern.
My 2 cents
John
PS we definitely want the 'variable size/shape organised on a canvas'
use-case for Sakai page authoring. But this is likely to be different
to the 'dashboard' landing page which most closely corresponds to the
portal (newspaper) use-case. I would imagine Portfolio might be an
example where different sized and shaped boxes arranged on a page
might also make sense.
On 18 Apr 2008, at 23:56, Paul Zablosky wrote:
Allison,
Your discussion of the columns of different widths prompts me to
question the whole notion of having colums, and what their value is
to the user. With the original uPortal customization tools, columns
provided a crude organization of the display -- allowing users to
move portlet windows left or right by shifting them to the next
column. But with drag and drop the user can move the portlet through
a continuous space, dropping it anywhere, and columns become less
useful as a page organization model. As for columns that are
narrower than the portlet, we should remember that the user can
adjust the column widths -- so is there a reason to restrict the user
from dropping a portlet in a column that is too narrow? She can
always adjust the column width and retry the drag-and-drop -- so why
would we make extra work for her? Tangentially, we should remember
that it's possible to resize the portlet width -- dropping it into a
too-narrow column could just make it skinnier -- and this could be
reflected in the dimensions of the avatar (the avatar would get
narrower if it moved to a narrower column).
I suppose what I'm suggesting here is that before we get caught up in
how to deal with procrustean columns, we should think about just what
the column convention is useful for, and how much of it we need to
maintain. Right now portlet coordinates are column number and ordinal
position, but does it have to be that way? And right now column
boundaries are the way the user says "I want everything over here to
be just this wide, and no wider", but it's worth questioning just
what this means from the user's viewpoint.
The layout of boxes you show below doesn't fit into columns, but it
may make sense to the user. So what is our reason for prohibiting
it? I feel that having some sort of grid that portlets can snap to
makes sense, just to help the user make the layout look regular on
the screen, but your example suggests that simple columns may be both
more restrictive and more cumbersome than is necessary.
Paul
Allison Bloodworth wrote:
Hi there,
I definitely believe that we should support the i-Google style
preview that our 'drag and drop layout preview' pattern supports.
However, I had also not noticed before that (as Eli pointed out) the
iGoogle portlets are all the same size. If this pattern is used for
columns with different widths, I'm guessing this may complicate
things from both a coding and user perspective. For instance, how do
you clearly tell a user that they cannot drag a portlet from a wider
column into a narrow column? It may be that there would be enough
feedback with the fact that a drop target did not appear, but that
would be something I think we should user test. Another question
would be whether we even want to prevent that interaction...should
users be able to drag portlets around without worrying about column
width? I'm guessing the coding for this could be complicated. This
could result in a page like this:
<mime-attachment.png>
...but perhaps there *may* be contexts where this would make sense
(e.g. users organizing piles of photos if the Gallery every
implements this). I did a bit of searching on the web and it seems
like not too many portals (or design patterns) are dealing with at
least *moveable* portlets of differing widths yet, so this is
probably something that deserves more thinking and then inclusion in
our design patterns.
I had also been a bit confused by what was described as the more
"Yahoo!-style" interaction our Layout Customizer displayed, as I
hadn't been too involved in the Layout Customizer design process and
actually hadn't seen a (in the process of being dragged) portlet
avatar represented as a very small box before. Today I realized
why--*Yahoo! has apparently recently changed this interaction in
their portal*, though their drag-and-drop modules Design Pattern has
*not* been updated to reflect
it: http://developer.yahoo.com/ypatterns/pattern.php?pattern=dragdropmodules#.
If you hit "play" you will see that a half tone avatar is still used
here, as opposed to the very small box representing the portlet
which Layout Customizer (and My Yahoo!) is currently using. This is
the interaction I was more familiar with, and is represented by our
Drag-and-drop List Ordering Pattern
(http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+List+Ordering).
I had a short conversation with Gary about this a few weeks ago, and
he said that after the usability testing done on a more
i-Google-like implementation:
"One of the main concerns was keeping the drag avatar the same size
as the original portlet. With potentially very large portlets,
there were usability issues with having such a huge drag avatar,
jerk-like shifting in the page contents on drag, and sometimes
obscuring the drop target indicator with the drag avatar."
It sounds like this could be a real concern, but I'm wondering if
using a full-size half-tone avatar (which you can see through, so
the drop target is visible), which both Yahoo!'s *design pattern*
(not portal) and iGoogle use, might mitigate this problem in a more
effective way. This could be backed up by user testing, but I am
worried that users will not be able to see or understand the
interaction of a very small avatar, which they may not clearly be
able to understand is a representation of the portlet they are
dragging (because it is difficulty to make that mapping and is
likely not in accord with the user's mental model of what a portlet
looks like). With an avatar that is the same size which immediately
moves from the original spot when the user begins to drag it, the
mapping is much more clear.
I had also suggested to Gary that we make our drop target color very
different from the portal's theme colors (e.g. make it green) to
ensure users could see it. I would also recommend including this
info in the design pattern. Also, I thought the way the drop target
is placed right next to a portlet without any padding makes it
harder to see. I'd like to see it spaced about halfway between the
portlets in between which it is indicating a drop target.
After we figure out what to do with the portlet avatar styling for
the Layout Customizer if anyone is up for thinking through some of
this and updating the design patterns with me, let me know.
Thanks!
Allison
On Apr 16, 2008, at 4:54 PM, Daphne Ogle wrote:
Thanks Colin!
Looking at the results it does look like users had difficulty
understanding where the portlet would land based on the summary:
"Drop Target Indicators:
* Green bar is too small and not being noticed enough.
* Maybe make it thicker and with an arrow indicating where
portlet will go."
Perhaps we could include the bar and make it thicker along with the
igoogle dotted outline pattern? Not being involved in the testing,
it's difficult to understand exactly where the hang up was for
participants.
It looks like the link is broken to the original designs (off the
testing page Colin identified below). Assuming we have it
someplace,
we could do some additional testing with the new design and an
updated
version of the old one. Since so much changed between designs I'm
concerned that testing just the new design won't give us very good
comparison information.
That said, our current iteration is very full so we could sure use
some volunteer help doing the testing if we decide to go that route?
And takers? We could do pretty low intensive "hallway" testing so I
wouldn't expect it to take more than a day but we'd have to look at
it
closer to see what is required.
-Daphne
On Apr 16, 2008, at 4:38 PM, Colin Clark wrote:
Daphne,
Sorry for the confusion; we haven't renamed all the wiki pages to
reflect the new Layout Customizer name. The user test results are
located here:
http://wiki.fluidproject.org/display/fluid/Portlet+Layout+Manager+Results
The results, as I read them, suggest that some participants had
difficulty determining exactly where their portlet would land. On
the other hand, this test was performed with a prerelease version of
the component that was a bit buggier in some respects.
Hope this helps,
Colin
On 16-Apr-08, at 7:33 PM, Daphne Ogle wrote:
Does anyone know where the user testing results for the layout
customizer are? There doesn't seem to be a link off the main page
for the component and I haven't had luck with search (probably
don't know what terms to use).
Thanks!
-Daphne
On Apr 16, 2008, at 3:33 PM, Colin Clark wrote:
Hello designers,
We've been doing a lot of review and testing of the Layout
Customizer
component in preparation for the Fluid Infusion 0.3 release. One of
the things we've been thinking about is the behaviour of drag and
drop
in this component.
A couple of months ago, Gary and Shaw-Han did a great job of putting
together some detailed mockups. They're available at:
http://wiki.fluidproject.org/display/fluid/Portlet+Reorderer+Mockups
If you notice, these mockups specify an approach that is very
similar
to myYahoo's news portal, available at http://cm.my.yahoo.com/. The
noteworthy features of this approach are:
* the use of a small drag "avatar" (the thing that follows your
mouse during a drag operation)
* a coloured, horizontal bar representing the drop target (the spot
where the thing will land when you let go of the mouse)
Another approach to drag and drop layouts is documented in the Fluid
design pattern for Layout Preview:
http://wiki.fluidproject.org/display/fluid/Drag+and+Drop+-+Layout+Preview
This approach is similar to iGoogle, http://www.google.com/ig.
Noteworthy features include:
* the use of a full-sized, transparent drag avatar that shows the
whole portlet
* a full-sized outlined box for the drop target
* other portlets on the page shift out of the way to show a
realistic preview of how the layout will look
What's the best approach? I'm thinking this is one of those "it
depends" questions. When portlets are similar in size and closely
spaced, the myYahoo approach is probably simpler and easier to
control. When portlets are more widely spaced and may have different
sizes, a full preview of the layout seems more useful.
At the time of the original designs, it's my understanding that we
went with the myYahoo-style interaction because it was immediately
similar to some existing code we have in the Reorderer. On the other
hand, the Reorderer is highly customizable. The dev team tells me
that
implementing both behaviours should be relatively straightforward.
It
may impact our release date a bit, but should we consider taking the
time to provide an option that will allow for the iGoogle-style of
preview?
I'd really appreciate opinions and advice from designers in the
community.
Colin
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
_______________________________________________
fluid-work mailing list
[email protected] <mailto:[email protected]>
http://fluidproject.org/mailman/listinfo/fluid-work
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
cell (510)847-0308
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org
Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
cell (510)847-0308
_______________________________________________
fluid-work mailing list
[email protected] <mailto:[email protected]>
http://fluidproject.org/mailman/listinfo/fluid-work
Allison Bloodworth
Senior User Interaction Designer
Educational Technology Services
University of California, Berkeley
(415) 377-8243
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
------------------------------------------------------------------------
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected] <mailto:[email protected]>
http://fluidproject.org/mailman/listinfo/fluid-work
_______________________________________________
fluid-work mailing list
[email protected]
http://fluidproject.org/mailman/listinfo/fluid-work
