- Platform for Economic Inclusion
- Preference Editing Tools Design
- Fluid Infusion
- Design Handbook
- Social Justice Repair Kit
We had another good meeting this morning to continue moving our process definition forward. We spent the majority of time discussing the idea/definition of "content management" as the scope of our evaluations. There is some concern about the semantics of "Content management" since many people then jump to thinking about 'Content Management Systems' which is not what we mean here. But we decided it was the best term (at this point) and we just need to be clear about how we are using it. As expressed on the wiki, http://wiki.fluidproject.org/display/fluid/UX+Walkthrough+Protocol+Working+Page, "Content management is being loosely defined as authoring, maintaining, organizing, viewing and sharing content...in this case digital content." We had some particularly interesting conversations about what this means for UPortal. Are we referring to the portlets as content or is the content within the portlets the content, or? In the end I think we decided both are and that different usage scenarios will have us focusing on various aspects.
We also discussed the various user types affected. End users are affected by their interaction with the product but should we also be thinking about developers and designers who build tools (Moodle and Sakai) and portlets (UPortal) that interact with and/or manage content.
In fleshing out a few UPortal scenarios, in scenario form, Paul described how users probably don't think about portlets as individual applications but rather the portlet as the application (so even though on the backend the portal has no idea what is in the portlets it holds, typical end-user expectations may differ). This was interesting from a couple different aspects. First, this somewhat parallels the "tool silo" problem we so often talk about with Sakai. The other thing I found interesting is a reminder of how valuable it is to focus on user scenarios (stories about real users getting real work done) while we do this work. Without scenarios it is too easy to make assumptions based on the way the systems are implemented that then place constraints on our thinking. In other words, we could find ourselves evaluating each tool or portlet in a silo which wouldn't be as useful as understanding how users are required to move between tools and portlets to complete activities. We agreed that as we continue working on scenarios (defining and prioritizing) for each product we'll refine the scope of the evaluation and improve our understanding of what we mean by content management. Although the specifics will vary across products we recognize the importance of continually sharing and discussing between teams.
The 'to dos' for our next meeting on the 17th are:
- product evaluation teams will work on profiles and scenarios. So expect to hear from product coordinators soon (hint, hint coordinators ).
- individuals should look at at the reporting template on the wiki and make comments, adjustments, etc. by the next meeting. I'll assume no feedback means people are happy enough with it as a starting point. As with everything else, we'll continue to improve it as we go.
Thanks to all who participated! I found this a thought provoking and enlightening conversation about the distinctions and subtleties of the products themselves but also our work in thinking about cross-cutting activities, interactions, models, navigation, etc.! As always, please add, correct, etc to my recap as needed. I'll post this message as archived meeting notes.