Lance Speelmon - 06-Jul-2007 07:15 Michelle, Please have Andrew create you a branch called SAK-10581 from Resource's 2-4-x branch. You will check your work into this new branch. Thanks, L

Lance Speelmon - 06-Jul-2007 07:16 2007/7/5, Harriet Truscott: > > > How another company has done this: > > http://www.flickr.com/photo_zoom.gne?id=327097697&size=o

Lance Speelmon - 06-Jul-2007 07:17 From http://confluence.sakaiproject.org/confluence/x/N7U : Indiana's proposal for popup with description The basic need is to surface resource descriptions, since this is a common faculty complaint IU's proposal is a pop-up/hover frame that displays the description. IU is going to be rolling this out by the end of the month, and has an interest in seeing this merged with the Resources tool There is no disagreement about the value of surfacing descriptions, but it's not clear that a pop-up would be the best way to do this: descriptions can get quite long - couldn't this be a problem? there are already complaints about the current pop-up menus; wouldn't a new pop-up simply exacerbate this? a pop-up tacitly states that the description is secondary, but isn't it often more important than most of the fields already displayed by the Resources tool? the Resources Viewer already treats this problem, although that can argue both for and against the pop-up solution (e.g. if the viewing is happening in RV, clutter in the Resources listing may be a little less worrisome) if we're going to do a pop-up, maybe it should show more than just the description picture on how someone else has done this: http://www.flickr.com/photo_zoom.gne?id=327097697&size=o We should move ahead with IU's proposal in a new branch, and then conduct some usability testing with it Action item: someone at IU will create a Jira for this, following the new convention, and the new branch will be named after this JIRA we may include this for 2.5 (with options to enable it, but off by default), depending on usability testing and other community feedback

Michelle Wagner - 18-Jul-2007 08:53 After getting a mixed response for the best strategy for this feature, I consulted with our designer, Rob, and we came up with a new approach. There will be an "informational" icon to the right of the resource link that will display the description upon hover. This solved the conflicts related to the existing hover text associated with the link and eliminated the requirement for a time delay on the popup (which was proving more difficult than it sounds...) This solution has been committed to content/branches/SAK-10581 and is up for debate. The css is currently located within the vm file and should probably be moved to the tool.css when a consensus is reached. There is also a new icon (thanks Rob!) in reference. Content commit: r32681 Reference (new icon): r32679

Michelle Wagner - 18-Jul-2007 09:03 I should probably also mention that the icon will only display if a description exists for the resource.

Michelle Wagner - 23-Jul-2007 14:21 r33010 Added 300 ms delay on display

Clay Fenlason - 23-Jul-2007 14:59 I'll see about serving it up locally for a look, but could you also post a screen, Michelle? Might help get the conversation started.

Ryan Lowe - 24-Jul-2007 08:21 r33024 Changed the 300ms delay to 400ms and also added the same delay to the other popups on the page for the "Add" and "Actions" menus listed next to each resource and folder.

Stuart Freeman - 24-Jul-2007 11:39 When I put this branch into my checkout of sakai trunk I get a NPE when I try to use the resources tool: org.sakaiproject.portal.api.PortalHandlerException: org.sakaiproject.tool.api.ToolException     at org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:887) caused by: org.sakaiproject.tool.api.ToolException     at org.sakaiproject.cheftool.ToolServlet.doGet(ToolServlet.java:227) caused by: java.lang.reflect.InvocationTargetException     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) caused by: java.lang.NullPointerException     at org.sakaiproject.content.tool.ResourcesAction.buildListContext(ResourcesAction.java:4492)     at org.sakaiproject.content.tool.ResourcesAction.buildMainPanelContext(ResourcesAction.java:4889)     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)     at java.lang.reflect.Method.invoke(Method.java:585)     at org.sakaiproject.cheftool.VelocityPortletPaneledAction.toolModeDispatch(VelocityPortletPaneledAction.java:393)     at org.sakaiproject.cheftool.ToolServlet.doGet(ToolServlet.java:227)     at org.sakaiproject.cheftool.VelocityPortletPaneledAction.doGet(VelocityPortletPaneledAction.java:1006)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)     at org.sakaiproject.vm.ComponentServlet.service(ComponentServlet.java:56)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)     at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:555)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)     at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)     at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:469)     at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:364)     at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)     at org.sakaiproject.tool.impl.ActiveToolComponent$MyActiveTool.forward(ActiveToolComponent.java:459)     at org.sakaiproject.portal.charon.SkinnableCharonPortal.forwardTool(SkinnableCharonPortal.java:1338)     at org.sakaiproject.portal.charon.handlers.ToolHandler.doTool(ToolHandler.java:163)     at org.sakaiproject.portal.charon.handlers.ToolHandler.doGet(ToolHandler.java:86)     at org.sakaiproject.portal.charon.SkinnableCharonPortal.doGet(SkinnableCharonPortal.java:887)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)     at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)     at org.sakaiproject.util.RequestFilter.doFilter(RequestFilter.java:592)     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)     at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)     at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)     at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)     at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)     at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)     at java.lang.Thread.run(Thread.java:595)

Michelle Wagner - 29-Aug-2007 07:48 I was told that someone else with more UI design and user experience expertise was taking this on. Does anyone know if that is the case? The current solution met IU's needs, but it sounded like the community had different needs and/or plans for this feature for 2.5.

Jim Eng - 30-Aug-2007 11:07 I'd appreciate comments in this ticket about two questions: 1) From a design and usability perspective, should this be included in trunk for 2.5.0? 2) What would need to be done to include this in the release? (Is it just a matter of applying a patch, or do we need to do additional design work?)

Michelle Wagner - 30-Aug-2007 11:30 Attaching screenshots of IU's instance. Imagine the mouse hovering over the icon where the description is displayed on the second pic.

Colin Clark - 04-Sep-2007 14:20 I haven't had a chance to see this in action yet, but from the screenshots it's hard to tell if this UI is also usable with the keyboard. DHTML is cool, but we need to make sure this functionality is available to non-mouse users, too. If it is usable with the keyboard, great work!

Michelle Wagner - 05-Sep-2007 05:18 Hi Colin, This solution is not currently usable with the keyboard. When we were going to make the hover over the link, I added the javascript that would display the description upon focus. But when we changed to hover over the image, I wasn't sure how to allow the user to focus on the image without making it a link, as well. I left the original javascript in there in case someone else knew how to approach this and wouldn't have to start from scratch.

Colin Clark - 05-Sep-2007 07:12 I think this is a good first start at an improvement. Nice work! However, given the lack of keyboard accessibility, I'd suggest it's just not ready for prime time yet. One of the things I expect to see resulting from Fluid's tweaks to the More Sites UI is a little library of keyboard handlers that people can reuse for things like this. Another option in this case is to reuse an accessible widget from an existing JS toolkit. Dojo comes to mind again here; they have a Tool Tip widget that is close in functionality to this. On the other hand, I'm not convinced this is the best option from a usability perspective; it feels like another layer bolted on top as workaround to deeper issues.

Diana Lee Perpich - 25-Sep-2007 08:08 I agree that this is a good first start. In my experience, students and instructors often want to view *more than one* description at a time. They also need to be able to mouse-away from the description and still see it. Some examples... My instructor has posted 10 images in a folder, each with a description. I need to decide which one to use for my project based on the descriptive text. I really want to compare my favorite three directly, but can't find a way to view more than one description at once. Or My instructor has used the description to post very specific directions about how to manipulate the image I've selected for my project. I need to manipulate it in Photoshop, but every time I move my mouse away from the floating description field, the description disappears. A right-sized javascript pop-up window for each description isn't very eloquent, but would allow for both multiple description viewing and persistent description viewing. Another option might be for the instructor to evoke an Option to show/hide list columns she deemed critical for her students. I've visited a million sites, for instance, where the Access column is completely filled down with "Entire Site," the Created By column completely filled down with the instructor's name, and the Modified column all set to the first week in September. Perhaps the instructor could opt to hide these three columns (and I'd throw size in there too-- size does not always matter) and display the description by default, kind of like she has options to show the message or not in the Recent Announcements and also Announcements list. Or, a dropdown View option for the user. Besides the slick "I" icons, they might select "Title and Description" view to get a persistent, multi-description view.

Michelle Wagner - 04-Dec-2007 18:50 Is there someone else able to take this to the next step? I don't think I will be able to take this further, and I don't want it to get lost. Thanks!

Clay Fenlason - 05-Dec-2007 14:55 My read of the conversation thus far has been expressed admirably by Colin: "I'm not convinced this is the best option from a usability perspective; it feels like another layer bolted on top as workaround to deeper issues." The root issue in my view is a lack of configurability in the list display, and not merely that the description isn't available. I therefore also think that Diana is right, and that a better answer to the root problem is to allow site maintainers to optionally include the columns of properties they wish to see. If given the option, my experience is also that the vast majority of them would include the "description" over other available fields.

Lance Speelmon - 05-Dec-2007 15:01 Yes, but could we not make some forward motion on this issue until the UI can be reexamined and re-factored properly? Our faculty have responded very positively to this enhancement and I do not want to lose the immediate value waiting on an uncertain future. Thanks, L

Clay Fenlason - 05-Dec-2007 15:23 I'm concerned that there seems sufficient reason to doubt that this really is "forward." It may be the kind of forward that one feels when one is painting oneself deeper into a corner. We already have complaints at Georgia Tech about the popups in the action links - switching from hovers to clicks (from 2.4 to 2.5) helps here, but we certainly don't want to re-create the problem in another column of the display as well. Add in the accessibility concerns among others expressed, and I think merging the work in in its present form would be ill-advised.

Clay Fenlason - 05-Dec-2007 15:35 We'll go a step further to try to give this a fair shake, though - I don't mean to discourage the work. We'll merge it in with local code (including our skin) and have instructional design people take a look. Maybe Colin can offer a further tip for making this work accessible, and we might be able to help tweak it. All this to say, I can help try to get this to the next step. We do appreciate the effort, Michelle.

Harriet Truscott - 06-Dec-2007 06:44 I would agree with Diana on this too. Just FYI - I recently came across an interesting related issue while doing a walk-through with an older Professor. He came to the Resources tool, which contained all the lecture handouts for that course. Thus all the resources had titles like 'Lecture 1 - the ear'. He interpreted the 'uploaded by' and 'date uploaded' columns as containing the name of the lecturer and the lecture date. Which of course makes sense when you looked at the page - as what each column said was effectively 'Lecture 1 - the ear, J. Donaldson, 23 Sept 07'.

Michelle Wagner - 17-Dec-2007 07:19 Lowering the priority

Lance Speelmon - 17-Dec-2007 07:27 I talked to Colin about this at the conference. I told him I am fine changing the hover to a click as I tend to think that hovers should be used more sparingly. He said they would take a look at it. Thanks, L

Michelle Wagner - 17-Dec-2007 14:34 Assigning to Colin per Lance's comment

Salwa Khan - 14-Jan-2008 09:27 Will the "hover over" to see a description function be a part of 2.5? Is there continuing interest/work on creating a description field that could be displayed without having to hover over? Thanks!

Salwa Khan - 14-Apr-2008 11:02 What is the latest on this issue? Will the hover over to see the description be part of 2.5? Is there a continuing effort to incorporate visible descriptions without the hover over function? Thanks for any information!