Child pages
  • DRAFT Preliminary Capability Enhancement Ideas for Lesson Builder
Skip to end of metadata
Go to start of metadata

INTRODUCTION

The Teaching and Learning Group is reaching out to get feedback from developers, PMC members and the larger Sakai community on some of the work that has been done over the past few months.  We are hoping that folks can take 10-15 minutes to review a draft document and post some comments by Monday, December 2, 2013.

WHAT WE NEED HELP WITH...

The Teaching and Learning Group has spent the past month or so working to develop a PRELIMINARY list of enhancements for Lessons/Lesson Builder that is called for in Phase One of the T&L Capability Review Process. The idea is to create an "unfiltered" list early in our work, which was suggested by developers in prior feedback, of any and all ideas the group has for enhancements as means to get initial feedback from developers.  We hope this will allow the T&L group to become aware of technical challenges, other related work that may be going on already in the community and some understanding of resource needs to implement the enhancement.

We have started to develop a Preliminary Enhancement List using a Google Spreadsheet but are unsure if the information it contains or the format will meet the needs of developers.  Thus, before we continue to work on it, we wanted to pause and hear from developers directly.  More specifically, we are hoping to hear back on questions such as:

  1. Is it useful to express ideas as "user needs" and "user scenarios/stories"?
  2. Is it useful to include suggestions for how user needs might be best addressed?
  3. Would it be useful if the T&L group ranked the importance of each idea?
  4. Did the way the spreadsheet was formatted work for you?  If not, how could it be improved?
  5. What would be the easiest way for you to provide feedback, would you prefer to add comments directly to the spreadsheet? Confluence?

HOW TO REVIEW AND COMMENT ON OUR DRAFT WORK...

We would recommend the following steps for reviewing and commenting on this work:

  1. If you are unfamiliar with the proposed T&L Capability Review Process you should briefly review it.  We are currently working on "Phase One".
  2. To help orient community members to what is contained in the Google Spreadsheet, we have created a PDF Spreadsheet Guide which has comments embedded that will describe the intent of each column.  We would recommend that you have this PDF open when reviewing the spreadsheet.
  3. Access the T&L Capability Review: Lesson Builder (DRAFT) Google Spreadsheet and review the approach we are taking.
  4. Post comments to this Confluence page (see below) responding to the questions above or simply with any comments or feedback

 **Important** > Although you are free to provide any and all feedback, we are primarily interested in thoughts regarding the process and format we are using and not the content.  We will be seeking feedback on the content specifically at a later date.

  • No labels

3 Comments

  1. I have only had a brief look through the spreadsheet, so my reaction is probably one of ignorance as much as of substance. I see that there has clearly been a lot of thought and time put into the materials.

    I don't know what the conversations have been like, but from an uninvolved developer's perspective, that is part of the issue: the spreadsheet is a little more in the formation of a solution set than a problem-and-solution set. More specifically, the user scenarios have a lot of narrative context, which is helpful to establish perspective, but the User Need column is in many cases very loaded and "already processed". It's a spec with an unknown level of vetting.

    For example, "Make conditional release more broadly available" is the kind of shorthand I would expect a developer to use once the user goals and technical details are well in hand – as-is, this is not written as a a user goal, but as a task for developers, "already figured out". Most of the User Needs are written in this way, which I suspect will be constrictive of the conversation that should happen to really suss out the details that would make a feature acceptable to users and technically practicable.

    My recommendation would be to work on writing the User Needs as User Stories. That is, express what a specific kind of user wants to achieve and why (without the inline narrative like "He's confused by..." or "I click on X and Y happens"). This formation invites conversation such as "why do you want to X instead of Y?" and "can you explain more about what's most important to you at that moment?". These conversations drive out acceptance criteria from the user perspective, usually about the end goals, but (very) occasionally about fine details like buttons on specific screens. It's a higher level starting point that lets the technical people ask questions to understand the user needs at a level of detail that is impossible with descriptions like "Organize LB menu items so options can be found more easily". The conversation is worth significantly more than the written summary.

    There are some great references on effective user stories. Mike Cohn is one of the foremost authors in this space, and also publishes free materials online. There are plenty of other good resources, too. Here are a few links (some decidedly Agile- or Scrum-oriented, though they apply broadly):

    Again, I don't mean this to be too critical of the work. I know all too well how much work goes into things like this. I am just reacting as a developer trying to parse a lot of information in which the user goals and technical assumptions are not evident to me. All the same, I congratulate those taking on this work; you have my support and gratitude for moving the community forward.

  2. Thanks again for your great work and effort.

    Noah is right, the user stories are loaded. But do provide for a great narrative to help prioritize features. This is just a question of step wise refinement and can be expected as groups with different skill sets start to negotiate.  Well done! The most important elements are in place.The spreadsheet is a tangible from which specific priorities can be set, discussed, merged and enacted. Thank you T&L for moving the process forward.

    I am curious about the reaction of the LOI in Holland as they have a similar tool to lessons builder. Mark Breuker is the contact point and I have sent him an e-mail asking for the LOI's reactions.

    Over the specific set of features requested. A number of elements seem like polish such as the print function, which you see in the evolution of other tools within CLE. I wonder if a knock on effect will be to push consistency of these features throughout CLE.

    I usually do not endorse a tool to play with, but for discussions with colleges over stories and GUI flow I use http://www.mockflow.com/ There is a free account. It is one of many tools that does this. It costs work, but might be nice to experiment with.

    You are on the right track. I can only agree and quote Noah: 'you have my support and gratitude for moving the community forward'.

  3. I'll answer the questions one by one ...

     

    1. I'd say it's incredibly useful to express ideas as user stories. As developers we try and talk to stakeholders, but, still, we are usually working in the abstract as most of us don't actually teach with the software we write.
    2. Helpful, to a degree, especially the odd UI idea. Point one is way more useful though.
    3. Yes, ranking of stories by tool is useful when prioritising, definitely.
    4. Generally, it's fine, although the rightmost columns for each participant seem a bit much, especially seeing how sparsely populated they are.
    5. I think Confluence is best for comments, or even the T&L list. I don't think it's a good idea to clutter the spreadsheet up. Keep it focused on the stories.

    This is good stuff. Like I hinted, coding in the abstract is not ideal and efforts like this will yield good results, helping developers and teachers to bridge their efforts. I hope so anyway. Keep up the good work.