Template talk:Learning Design

see: http://meta.wikimedia.org/wiki/ParserFunctions

i'm trying to do this in a real Wiki Way, not only because i can't be bothered with php, but because i think with a combination of the existing syntax of templates, the parser functions, categories and collaborative authoring we can figure out how to .. essentially do this: http://baach.de/phase3/index.php/Main_Page but ... well, better .. more Wiki like. This template, plus this: http://www.wikieducator.org/Learning_Design/project/Design_Decision_Guide/Auto_Blueprint_Testing_Zone are projects around organizing a 'content community', a community of producers in service to consumers. suggestions welcome. Essentially we are trying also to establish a 'school' or name'space' where consideration of this possible/eventual/emergent practice and it's relation to projects, content authors, editors, graphic/multimdedia specialists, educational technologists, wiki gardeners, gnomes and fairies might investigate. brent 14:25, 10 May 2007 (CEST)


 * Brent this approach is perfect for the LD process - we can use FlaggedRevs for Peer review/quality control stuff. The advantage with FlagedRevs - is that we could potentially assign Web-of-trust candidates or educational gurus sanctioned by particular communities to take responsibility for peer review. For example, in the VUSSC community senior educators from VUSSC member countries take on peer review. However the content development process is done the wiki way - as it should be! I've very excited by this project. This is a major innovation. --Mackiwg 04:12, 12 May 2007 (CEST)

--Mackiwg 03:57, 12 May 2007 (CEST)

WOW!
Brent - there is some pretty cool stuff underneath the hood of this template. I'm amazed at the power of Mediawiki and your hacker skills for this particular implementation. This will take WikiEducator places.

This is like the old innovation days at CFDL - only better! --Mackiwg 03:57, 12 May 2007 (CEST)


 * Wayne: thanks. I'm pretty amazed as well! Have been having real fun with this and got me thinking that there's a lot that can be done just working with the already existing tools that are available in the platform. With smart use of the Template, Parser Functions, and Category syntax you can get some quite sophisticated stuff going. brent 04:08, 12 May 2007 (CEST)

Thoughts on the LD Boilerplate
Hi Brent,

I started having a play with the LD template you put on the Content page. (It's a little abstract in the sense that you would not typically be doing learning design on a page like this - but the example has helped me think through a few issues.)

My thoughts on the Start Learning Design

Open questions & ideas:


 * How does this page /Learning_Design link to the LD template in the Learning Design namespace? - Although I like the idea that the LD page is linked to the relevant content page node.
 * On the boiler plate itself - it would be good to link to the resource that explains how all this works.
 * This may be difficult - but when a page like this is created for the first time - is it possible to embed a template with links to the relevant resources? This way the user will not need to go back to the parent page to find the links.

'My thoughts on Start Content Design


 * Rather than having content design as a separate sub-page - I'm wondering whether it would be better to have this as a major subheading on the learning design page for example .../Learning_Design#Content_Design. However this may be difficult to automate in MW. Perhaps we need to think of a work around.
 * What happens if a user inserts a design template on the Content design child page? Does it still know that "Content" is the parent - or does it assume that Content/Content_design is the new parent?

PS - I'm very impressed with the feature which changes the "Start Learning design" link to "Learning design" once in the page is created. How difficult is it to replace this with something like "Learning design - in progress"

My thoughts on Start Visual Design


 * Same as for "Start Content Design above"


 * Thoughts and queries above no longer valid - assuming we have a clear distinction between the design plan (created using the Decision Guide) and the implementation of the design plan using the boilerplate in conjunction with the check lists. --Mackiwg 23:14, 25 May 2007 (CEST)

--Mackiwg 17:53, 19 May 2007 (CEST)

Further thoughts on the Boilerplate - post Decision Guide experience
I've had the opportunity to spend a little more time thinking about the boilerplate template, after my first experience of completing the Decision Guide Template.

I like:


 * The sub-classification between the different design dimensions (CD, LD and VD)
 * Linking discussion sub-pages to check list criteria to help the community gage the developmental phase of a project
 * The ability to talk about the development on wiki-subpages.
 * The levels of automation embedded in the template

I'm not sure that:


 * We have linked the right criteria on the check list with each sub-phase
 * We have the right terminology for signifying the "state: of each phase of the development under the design sub categories

Here are a few thoughts to help guide refinements:


 * 1) There are two distinct components of our smart (...;-) ) learning design solutions:
 * 2) * The decision guide which leads to the dynamic development of a design plan ("blueprint")
 * 3) * Boiler plate which facilitates discussions and decisions on the state of the development of a design plan.
 * 4) We should avoid confusion between discussion on the design plan itself and discussion pertaining to the development process. For example: "I don't think that the delivery strategy will work because .... " should be on the talk page of the relevant design plan - and not the LD subpage generated by the boiler template. However "I don't agree that the LD checklist for the next phase of development has been achieved because ....." should be on the LD sub-page created with the boilerplate.
 * 5) I think we may need different descriptors to donate the state of the development for each design sub-category. In LD this may be - 1 = Design commenced 2= Design in progress and 3 = Preparing for QA. There may be other descriptors more appropriate for the other sub-categories.
 * 6) To avoid confusion we need clearly defined check list items for the sub-phases of each design category. We need a mechanism to decide when a project moves from one phase to another. For example:
 * 7) * On the LD sub-category the following check list items may be appropriate for each phase:
 * 8) ** Start learning design: Starting state is - No design plan. To move to the next state the check list items should be "Design plan completed" and "Link to design plan inserted"
 * 9) ** Design in progress: (1) Representative sample of materials completed (2) Feedback for improvements received (3) Design plan modified (4) Materials for resource completed (including for e.g. learner activities inserted, assessment plan implemented.
 * 10) ** Preparing for QA (1) Evaluation criteria specified (2) Comments on QA criteria received (3) Criteria refined - which would then go on to a state of "Ready for QA" which could be the last category for each design dimension. - see example table below
 * 11) * On the CD sub-category the following check list items may be appropriate for each phase:
 * 12) ** Start content design Starting state is no content outline. To move to the next state there must be (1) A content outline (Headings & subheadings specific - eg Topics, sections and subsections) (2) Estimation of notional study hours for each main section specified. (3) New pages created in WikiEducator for each subsection (4) Work-in-progress template inserted on each content page.
 * 13) ** Content under development: (1) Navigation templates inserted on each page (2) Content for all sections and subsections completed (3) Categories for each page inserted
 * 14) ** Preparing for QA: (1) All suggestions on talk-pages implemented /resolved
 * 15) * On the VD sub-category the following check list items may be appropriate. More to come .....

Ideas for Content design sub-phases and corresponding criteria
--Mackiwg 08:59, 24 May 2007 (CEST)


 * This is great Wayne - it tidies the thinking and pulls it together. I see the link now nicely to my more granular checklist.


 * It's a minor, but the only sub-category I'm not so sure about is the "Preparing for QA". Not sure that it is meaningful to everyone...perhaps something more along the lines of "Checking for quality" or something like that?


 * I think you're right - I'm not too comfortable with the preparing for QA label - but couldn't think of anything better at the time. "checking for quality" would describe the activities - but I like the idea of "ready for use" as the outcome of this sub-phase. What about - "Preparing for use" as you suggest below? --Mackiwg 02:44, 28 May 2007 (CEST)


 * Yep. Let's try that.--Fiona 04:05, 28 May 2007 (CEST)


 * Also, is it in here (the QA section) that that you envisage receiving "Peer Review" feedback? That is one of the areas I felt we hadn't addressed yet and was quite keen to see room for something more along the lines of an endorsement method - something quite open on the wiki whereby users or members of the "trusted group" offer comments. A bit like: |Philica. People interested in using the developed resource could then check out others' experience with it and whatever other comments they may have made about it. It's really a part of the evaluation process.--Fiona 01:53, 28 May 2007 (CEST)


 * I envisage two "types" of resource: (1) those that have undergone the LD process and are ready for use - but have not undergone a rigorous process of peer review. (2) Resources which have been Peer reviewed - and here I'm thinking about implementing the FlagedRevs technology. I see this as a separate consultancy. Our learning design process is formative quality assurance - whereas FlaggedRevs is a summative quality evaluation. Does this make sense? --Mackiwg 02:44, 28 May 2007 (CEST):


 * Makes sense - although it was the somewhat arbitrary choice of %value for these things that led me to thinking of the fuller checklist approach for the boilerplates. I remember at the bootcamp pulling a 'finished % figure' out of the air with Phsi. Does everything need to be automated? Isn't there room for fuller comments from people? You could go so far as to have an 'Endorsement' tab on each page of every completed resource where people can simply write a review.--Fiona 04:05, 28 May 2007 (CEST)


 * I agree the arbitrary %value of completion is not ideal - and it's better to have this linked with completion of the identified items on the check list (recoginising that these are still based on community evaluations). The check list approach is a vast improvement on the guess work on the % of completion approach. I think that there is some value in having a quick visual representation of the state of completion using a bar of sorts - but this should be linked to a more robust checklist scenario. For example - once the design plan is completed this may represent 15% completion. Once the next sub-phase of the development is competed this may represent 25%. We played around with an idea for completion bars for sub phases of the design process - take a look at the example on the bottom of this page. The automation should just be to make the visualisation easy for non technical users - but in my view is not a substitute for real dialogue on the talk pages. I like the idea of an endorsement tab - have a chat with Brent. Once the design reaches the point where its ready for requesting endorsements - the template can contain an "endorsement tab" which automatically directs the user to a sub-page for endorsements. That's a very good idea. So at the point in the design cycle where we need endorsements - the tab is displayed on the page. This gives rise to a criterion for this phase - namely sufficient endorsements recieved.  The difficulty I'm facing with sceptical organisations is related to the summative review of content by an "approved" group of peers. So in WikiEducator I'd like to cater to both worlds. The organic community development model which we are working on in this project - but then as a next phase the more "formal" QA review processes. These are not mutually exclusive because the summative QA process would not change anything in our organic design process - its just an added feature for those who want it without altering the integrity of the original content. --Mackiwg 04:31, 28 May 2007 (CEST)


 * I have an idea for a very simple visual representation, somewhat akin to the completion bars but a little more compact. I'll try to implement a demonstration of what I'm talking about soon. brent 04:42, 28 May 2007 (CEST)


 * I guess what we're doing here feels just about right then;-)Quick visuals, relating to less arbitrary checklist...of full design process...with summative feedback...not bad!--Fiona 04:55, 28 May 2007 (CEST)


 * Hey- the power of collaborative development! Can't wait to see Brent's concept idea - I know that its going to better than what's gone before. Linking this with the experience of real design processes is going to make the difference. I'm pretty impressed with our work on this project - we're pushing the envelope! --Mackiwg 05:06, 28 May 2007 (CEST)


 * One other thing - in my original list of possible subcategories for the boilerplate, I included the category "Ready for use". Don't you think once a resource has undergone the entire LD, CD VD design and checking process, it needs to then carry a mark or indicator of some sort that shows it is "Ready for use"? I know these resources are ultimately always editable, changeable etc,and it will, within the category system, end up in a place for "ready" resources, but something that quickly denotes this - a stamp of approval!...qualmark:-) - might be useful.


 * Yes I like this idea - "Ready for use" means that the resource has undergone a full cycle of design - but not necessarily a formal process of peer review (the FlagedRevs stuff). FlaggedRevs will be able to extract the exact version that was peer reviewed - and distinguish this from ongoing edits.


 * Feel free to change my suggested labels - they're part of a process of ongoing refinement. Chat to you soon. --Mackiwg 02:44, 28 May 2007 (CEST)

Percentage completion & other thoughts
Started a new thread here - things were getting rather cluttered given the levels of high quality input :-).

Brent - I like the implementation indicating % completion. I recall seeing this graphic used in Wikibooks back in the early days of Wikiversity and liked it back then.

A few additional thoughts to add into the mix:


 * Should we look again at the choice of colour for the link-text of the different sub-phases. The contrast of some options seems difficult to read on my notebook - or is that because I need spectacles ..;-)
 * Once we have firmed up the functionality of this cool template - we could revisit the layout design - I think we can save a little real estate in the design.
 * This is the first time I noticed this that the title automatically includes the name of the page as in: "Learning design for learning design". Cool - I was just about to write a comment that Learning design for learning design doesn't make sense! - Should we be using a different colour for the page name?

[Wayne / Brent - While it may not seem obvious at this developmental stage, I think we have to think about "use" as well as "adoption" (i.e., so that users can actually use the Wiki and run with it...I'm thinking a bit beyond the innovator using WikiEducator, but some of the "early majority" for WikiEducator, and the communities that will have these individuals as champions / sponsors, etc. What I'm trying to get at here, is that if you look at corporate wiki suppliers - and I just spoke to one today - their competitive edge is NOT in terms of functionality, but in ease of navigation and overall 'prettiness'. So, colours to make it easier to read on the screen is great; placeholders for type; intuitive and friendly navigation elements are important; smart use of wiki real estate; even the oh-long forgotten principles of designing something that fits on a 15" screen, which is more likely to be the case in developing countries, the destination for our efforts. - Wikirandy
 * Do we need the heading current activity? Isn't this self explanatory - given the descriptive link labels. We've already stated that this resource is undergoing a process of learning design.
 * Is there a way of communicating to first time users that they can click on the Check mark icon. Perhaps in the info box once we've decided what the links to the support resources should be. May confusing for no technical users - when they click on the % graphic they go to the image. However the check mark is a clickable link. Minor useability issue because once you know how this works - it shouldn't be an issue. Perhaps this is a user training question.

The more I play with this template the more I like and I already have ideas about how we might use this for the Learning4Content project - where there is a process for identifying, selecting and "managing" wiki facilitators who will be giving the training.

--Mackiwg 00:38, 29 May 2007 (CEST)

# Switch .
Brent -

Currently the user must enter the correct order for |LD1|CD2|CD2 -

If the parameter is - is there a way to overcome the order in which the user enters the syntax -

for example CD=1|LD=2| ... that is using named parameters instead of numbered parameters?

May also be easier for the user - because then they don't need to remember the order in which to enter parameters.

--Mackiwg 03:12, 29 May 2007 (CEST)

PS - that was very quick on refining the template - I'm watching work as you progress!


 * That seems to have worked. Has changed the syntax to be now:

in whatever order you like. 6 more percentage templates to go! brent 05:26, 29 May 2007 (CEST)


 * I'm pleased that worked - wasn't sure about this, but thought it would. Just by chance I saw a template where it appeared that named paramaters could do this magic! VERY cool. We myst just remember to change the user instructions. This is just like the old days of innovation. - We're making a difference to the planet!

Test

A spanner in the works - Editorial design?
These past weeks I've been wondering where the Linguistic/Editorial design fits into our schema.

Traditionally language and usability (student friendly language) editing comes at the end of the process. However, under a wiki model there is no reason why this can't take place the wiki way - that is while work the resource is under development.

OK we cant use the label Linguistic Design (to avoid confusion with the abbreviation for Learning Design (LD)) - but it seems to me we need another sub-phase for Editorial design.

Chat to me off-line about the implications for adding the Editorial design component into the project.

Cheers --Mackiwg 07:02, 29 May 2007 (CEST)


 * You know it is still bugging me that we might be ‘overkilling’ the need here. When we think about what it is we are trying to enable, I keep wondering if we aren’t overcomplicating things. Forgive me if I am seriously off beam here, but I keep thinking about who might possibly be going to use these templates/tools and, in reality just how much time is going to be devoted to these structured discussions/processes. I know we have spoken about this, but I keep coming back (my perseverative self) to wanting to simplify….simplify…condense…not grow. So am actually thinking instead of adding more sub-options to this tool we should be taking away…


 * I actually think we only need two options: Learning Design and Content Design. I really believe that editorial AND visual design fall within the checklist for content design. They are a subset of it. Aren’t good visuals, use of media, voice, tone and readability a part of good content design?


 * This would mean the “Design Progress Tool” includes only two elements. We need to explain them well and provide for them within the resources we are creating and the checklists, but in terms of functionality and final production of a good WikiEducator resource, I don’t know that we benefit from adding more options to the tool. We want to keep the process clean and simple – effective, but provide the minimum to achieve it....another spanner in the works:-)  --Fiona 11:22, 30 May 2007 (CEST)

Good - thinking on refinements
I'm a great believer in the recursive nature of design - we end up with better products. The simpler we can make this process for the user - the better.


 * You have my vote for only two elements - ie LD & CD
 * Conceptually - I agree that we can deal with VD and Editorial design as sub-components of CD. This makes sense.

In the design plan - taking this development into account - once we have simplified the decision guide, we may need a subheading for "Visual and multimedia elements" where users think about the kinds of things related to visual design and editorial work. These can easily be one or two items on the CD checklist - depending on the phase of development.

I'm also thinking left brain here. There are many roles in the community, eg content experts, learning designers, linguists, multi-media experts, wiki-syntax gurus, learners, graphic designers etc. In building community it would be great if we had a way of easily identifying where folk can contribute their skills to live developments - without overcomplicating the boilerplate template. The link here will be the checklists. Checklist items could be associated with specific skills. Think of a two column table, where you list the checklist item with a corresponding mapping of the typical roles required for successful completion of the checklist item. This will help us identify the skills base required for different phases of the development.

I'm not thinking of an overly complex system here - but just simple way of communicating. For example phase 1 of CD needs content experts, LDs and some VD folk.

Fiona - I like the suggestions for simplifying - we're not loosing the VD and editorial aspects, but simply communicating this better. Go for it. --Mackiwg 22:34, 30 May 2007 (CEST)


 * OK, thanks. Will give some time to the checklists asap. In the meantime see below for more thoughts...--Fiona 23:49, 30 May 2007 (CEST)

Further refinements
It seems to beg the question of how all of this links right back to the Main page on the wiki…Brent and I had a chat about this yesterday. If you go right back to entering the wiki, there are (apparently) three main reasons why people come in:1) to browse 2) to use existing resources 3)to contribute and create resources.

If you come to wikiEducator and decide to contribute or create resources your path might look something like this: Main page >Using wikiEducator>Contribute and Create resources>

So we probably need to create a new page: Contributing and Creating Resources for WikiEducator on which to hang Learning Design and Content Design information and resources. This page would introduce the rationale for design for wikieducator – the importance of LD and CD. It would include the design process (see below) and links off to the Design Guide, Progress tool and mini tuts on how to use them. So, it means just a slight shift away from a page devoted solely to Learning Design to one which is more broadly about designing resources (LD and CD) for WikiEd. Does that make sense?--Fiona 23:49, 30 May 2007 (CEST)

Also, as a very first draft, the design process might look something like this to link with the Progress Tool (boilerplate)…?




 * Yep that makes sense. The main navigation path should be as simple as possible for the majority of users - so I like the generic path of: Main page >Using wikiEducator>Contribute and Create resources>


 * The graphic explaining the process is great! - Don't spend too much time making graphics pretty, we can do this on our end. The concept is more important. No problems from my side with the suggested shift away from a learning design page to this new idea of Creating resources for WIkiEducator. This is the power of the wiki given its networked structure.


 * At the same time (for the future) we will need to think about different categories of users. For example, Newbies, intermediates and WikiEducator experts. Intermediates may be more interested in the tools, special templates etc to support and enhance work in WikiEducator. Experts may be interested in other things. Therefore in the future we may need other pages that are structured differently. Not too replace the newbie path - but to cater for different paths and different needs as the community grows and matures. (Almost like creating a career path within WikiEducator for wikieducator users.) However - our first priority in this project are for Wikinewbies someone who wants to create a resource, so I very pleased with these developments and suggested refinements.


 * The more complicated stuff is for later

--Mackiwg 01:38, 31 May 2007 (CEST)

Back to Design Progress Tool
How about this if we are going to run with LD and CD only? The 'Actions' and 'Outputs' can then appear on the checklist pages that link from the tool when it is in use.

I've been referring to the thing as the Design Progress Tool...are we going to stick with that?--Fiona 04:32, 12 June 2007 (CEST)


 * I'm not sure whether the concept of "Design Progress Tool" is the best concept - that said, I don't have a better alternative to suggest ..;-(. Any ideas?
 * I've added a WikiEducator tools/resources column to the tables below. As a result of the addition there are one or two additional template requirements have been identified - I'll be able to work on developing some of these in the near future. --Mackiwg 05:29, 22 June 2007 (CEST)


 * Yep that looks good. I hadn't included checks for inserting the tool/template itself as I was conceptualising the process from the point at which the thing was already in action on the page. In other words, this was being generated from the tool/template. Get me? However, your additions makes these checks usable from multiple starting points eg the Resource Development page, or the associated tutorial or some other page.


 * Yeah - the advantage (or disadvantage?) of many eyes . I may be confusing things - but not sure if I understand the 'generated from ' the tool scenario. No doubt I'm missing something because of my age . I see the the check list as a basis for developing consensus with the community on whether to move from one sub-phase to the next. Specifying specific actions may help the decision-making process using the checklist to determine if the project can move to the next phase. All speculative of course. For example, where do we tell folk to change the status of the template from LD1 to LD 2?


 * Re the name - I'm totally open to suggestion. 'Boilerplate' just wasn't a concept people understood that well when I did my 'informal analysis' --Fiona 08:16, 22 June 2007 (CEST)


 * You're absolutely right. I think 'Boilerplate' is considerably worse! Like I said - I don't have a better suggestion - sorry. Decision guide tool - describes what this is, but is akin to my awful noun phrases. Bottom line if we don't come up with a better concept - it will work. We just need to explain it well! --Mackiwg 08:36, 22 June 2007 (CEST)