Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Basbrands
1. Project THNK
Building a Collaboration tool for the Amsterdam
School of Leadership, THNK, using Moodle
Bas Brands
Moodle developer
BrightAlley NL
2. This is my team..
Team Networks
donderdag 14 maart 2013
3. This is the client…
THNK: The Amsterdam school of
creative leadership
THNK provides a 18-month, part-time, post-graduate
program for a carefully selected group of international top
talent
donderdag 14 maart 2013
18. Plugins that were never used
Custom search
Stream
donderdag 14 maart 2013
19. Lessons learnt
Do less (use dummy functionality)
Show progress
Share plugins / blocks when you can
Use consistent user interface designs
Never hack!
donderdag 14 maart 2013
20. Was Moodle the right tool?
YES
The flexibility allowed us to build all we wanted
Code will be re-used for 2nd version
NO
Client did not always like the “Moodle way” of user interaction
There was too much to customize
donderdag 14 maart 2013
Notas del editor
This is my team at BrightAlley, we are the Moodle team within BrightAlley which has more than 60 employees working on learning projects.With this group of people and some others we deliver Moodle services which include:HostingService and supportCustomizationsThemingIntegrationsConsultancyCourse design
This presentation is about a project we did for THNK. The Amsterdam school of creative leadershipTHNK has started a project to educate creative leaders. It aims at the top of the learning market they can be called Hip, New, well connected, educated.
The THNK team has a vision: They want to build a community of people that work together, build social networks online and offline. The have a playful way of teacher and learning. The main reason to join the THNK program is because of the Network you will build while attending the program.To be able to share knowledge and connect they needed a interactive, closed, online social platform.
Most of the collaboration / learning / dancing is done offline at the Westergasfabriek in Amsterdam. The online part is there to facilitate the offline. Examples of these are Challenges: A group of learners is formed that work together on a challenge: “How to stop drought in a specific developing country”Learners work on these challenges in a online Collaboration tool and talk about it in groups offline.
Job and the THNK team entered a VISIONING phase. With a team of key users in the THNK organization they did brainstorm sessions to create a visioning document that included the learning experiences , Tools and data that was needed in this online platform.This document was used as the Blueprint for the Tool to be build
Job than consulted his team (us) to see how we could deliver such a tool.We are a team that works on Moodle project so the main question Job had to ask was “Can we do this with Moodle and Should we do this with Moodle”We made a list of pros and cons to make a well balanced decision on this and accepted the Challenge
Some of these pros were:Moodle has a big community and a lot of plugins are already there. Moodle is well documented for users and developers.We can build plugins that add to Moodle and plugins that alter its behavior..The most important pro is:Most of the requested features that came out of the Visioning stage of the project are already in Moodle
We had doubts before we accepted the project.Could we really customize Moodle enough? Could do everything that was asked for.Of course Moodle is a huge tool with many many options and what about all the stuff they don’t need: Many course modules, blocks, mymoodlepages, profile pages, category views, course views etcetcIf we want to have it exactly as the client requests we might need to build it all from scratch..
Since we accepted the challenge to build the THNK tool in Moodle we started the projectOur standard approach for project is:We start a scope session with all involved parties: Client, Consultants, Developers, Graphic designers, Functional designers and have a open discussion about the Visioning documentFrom there a technical design with estimates is created. This describes the rough technical outline for the project and cuts it into parts that need to be developed. For each of this parts an estimate is given.The functional design describes how the tool is used and what needs to be setup to make it workThe graphic design describes the general styling to be used by the tool.These designs were all printed and put up on the wall so everybody can watch them and the idea can really sink in.
Since I was the developer on this project I got to write the technical design and divided it into the to be developed chunks. (see slide)Some of these were nice separate bits of code that could easily be done as a separate plugin. Some had complicated tentacles that found their way into moodle core code.
My main problem was TIME.Not only was the number of plugins and code to be developed huge, I did also need to work on other ongoing projects. This bit of code explains what happenedThere is a certain amount of time needed to work on the project.If you don’t have enough time you can simply hire a developerThis developer did not have enough time to do it all either. So his solution was to: Hire a developer.With this construction it is hard to keep code consistent and clean. Not only from the backend but also from the frontend
Our consultants had some problems when creating a functional design.Since Moodle is already build with a certain pedagogical model in mind things are build using a certain logic. Most of Moodle’s tools use a standardized way of user interaction using forms buttons and layout.The client (just kidding with the wheelchair guy) Does not know how Moodle works and wants the tool to be a combination of tools they do know:Dropbox for it’s easy filesharingYammer for it’s nice stream of updatesLinkedin for it’s networking capabilitiesFacebook for your personal profile etc etc.
Since most users login using LinkedIn we have a user avatar on the Connect page.You can filter the list of users that is shown through Skills. These skills can be ticked on a users profile page.Everything works using Ajax and sliding menus which are very quick and easy from a user’s perspective.
Logging in is made easy with LinkedIn. This opened the tool for everybody with a linkedIn account so other ways of controlling access to the protected parts were created.The LinkedIn authentication module + the linkedIn block were shared on Moodle.org and are still being supported. Currently these have been downloaded over 500 times.
A custom course format was created where some of the custom modules live.This course format was based on the collapsed topics format but rewritten to fit the desired design.Modules were not added as links to the full module pages but shown inline in the course page.All modules were created to work with Ajax to enable quick changes and use a mix of YUI and JQuery
The OU Wiki was used and lots of effort was put into styling it through the theme.There were many other small modifications done and plugins built. But that was not the topic of this presentation. This presentation evaluates the project and presents the lessons learnt. So after 18 slides of introduction these are the results: (next slide)
We started building too soon. Some of the features created were never used. We might as well have build a dummyWe needed to test more, it is embarrassing to have too many bugs on delivery.Sharing the code (linkedIn) gave me a drive to produce better code because the audience was getting bigger. (and we got free testers)
Was Moodle the right Tool?Yes and NoYesIt did give us the flexibility we were after. As long as coding guidelines and UX guidelines are there and being followed it can be a tool to build complex systems from. NoThis client did not know Moodle and all its features, quirks, it’s community and philosophy. Moodle is not a framework, it is a big Tool build from plugins that have always been and made it to Core. Moodle is evolving. In evolution too much specialization makes you more vulnerable to changes.