August 3rd, 2012 // By lux
Watch This Space...
The Team @ Dojo Learning
April 23rd, 2010 // By les
We are closing shop May 1, 2010.
Lux an Les
March 13th, 2009 // By les
This is the second article in the series: ABC's of Lesson Development. This article builds on language introduced in Part I.
For example, if you are providing consulting on how to become a great Internet Marketer, you need to capture all the skills, knowledge and judgements (KSJ's) that are required to become an Internet Marketer. DACUM is one way you can capture these skills in order to develop custom training. Here is how the workshop process breaks down.
Step 1. Gather Subject Matter Experts (SME's)
This workshop process is like a focus group. The best way to discover all the KSJ's is to bring together a group of of SME's, in this case they would be Internet Marketers. If you are developing these materials on your own because you are the SME and you don't know any other experts, you can proceed through this process by yourself.
Step 2. Ask the question "In the course of my everyday work as a Internet Marker I..."
What follows next is a verb and a skill, knowledge or judgement. For example:
In the course of my everyday work as an Internet Marketer I...:
- Demonstrate reliability
- Write emails
- Implement web metrics
- Write marketing plans
- liaise with clients
Typically this process is completed over two days with groups of 8 - 10 experts and the list of KSJ's can exceed 100. This list is usually displayed on cards along a wall, but it can be expressed on paper just as well. If you are trying to develop more concise materials you can keep this list short or break a longer list into a multiple set of materials.
Step 3: Group the KSJ's in categories.
- write a blog
- record a podcasts
- comment on posts
- re-post links
- share news
- record video
- tweet messages
You can categorize these skills as "Communication." I've included an example of a DACUM chart that demonstrates how you can group your list of KSJs. This chart represents an entry level Art Advertising course that is delivered by a local college. Now you can make your own DACUM chart. A smaller version of the DACUM chart can be viewed below as well.
Step 4. Assign a Competence Level to Each KSJ (Optional)
- Can perform some parts of this skill satisfactorily but requires assistance and / or supervision to perform the entire skills.
- Can perform this skill satisfactorily but requires periodic assistance and / or supervision.
- Can perform this skill competently without assistance and/or supervision.
- Can perform this skill competently with more than acceptable speed and / or quality.
This helps you gauge how in-depth you may want to teach certain KSJ's. For example in the skill above "record video" you may not want to teach that as in depth as "tweet messages." If that is the case, I would assign a "2" to record video and a "3" to "Tweet Messages." This process really helps you focus your materials development to those skills that are most important and require more content than the less important skills.
This DACUM process is the standard for developing curriculum, and if you are a knowledge-based consultant or independent trainer this process is a great way to organize your training. In the next post we will explore how we can take the DACUM chart and create lessons in Dojo Learning. The ABC's of Lesson Development is a series on outcomes-bases lesson development and assessment. If you are interested in this series subscribe to our RSS feed and follow along.
March 2nd, 2009 // By les
This process is called Outcome-based Learning. An outcome is a conceptual container that holds all the knowledge, skills and judgements you need to accomplish the outcome. At the onset of each lesson the developer should complete the following sentence:
"At the end of this lesson my learners will be able to..."and what follows next is an action word, or verb, and the outcome.
Let's use the example of cleaning a kitchen in this sentence. At the end of this lesson, my learner will be able to Clean the Kitchen.
The learning outcome, Clean the Kitchen holds all the knowledge, skills and judgements (KSJ's) required to perform the outcome. Here is a list of KSJ's for the Clean the Kitchen outcome.
Safely use cleaning chemicals.
Prepare cleaning solutions using ratios.
Understand the appropriate tools for the appropriate job task.
Choose appropriate cleaning supplies for the job.
Choose appropriate cleaning tools for the job.
Assess when kitchen is clean.
These KSJ's are what you teach your clients if they are taking your How to Clean the Kitchen lesson. This framework provides the lesson developer with a road map for lesson development and a clear framework for you clients. This method is considered a best-practice in curriculum development and private trainers and consultants can use this method for developing their own materials too.
The next article in this series is on DACUM (Developing A CUrriculuM) which is a storyboard / workshop method that helps you develop KSJ's for your training. The ABC's of Lesson Development is a series on outcomes-bases lesson development and assessment. If you are interested in this series subscribe to our RSS feed and follow along.
February 24th, 2009 // By les
Funny Forklift Training Video
Bill Nye the Science Guy Video - the Water Cycle
Phil Kay - Comedy Health and Safety Video FULL VERSION
Chuck E. Cheese "University" Character Training
Pedestrian Crossing Training
Finger Safety - "It Can Happen to You!"
Awkward Chemistry Video that works
Don't You Put it in Your Mouth (Full Version)
1980's Wendy's Training Video
February 8th, 2009 // By lux
Software is easy to start, hard to finish
Persistence and hard work are the key to succeeding in software as in most things. If you can maintain the persistence, you'll keep going until you've made your wrong idea into a right one through subsequent iterations.
When we started Dojo, despite it being my 3rd company we still figured we could get something up and running in no time. We quickly discovered we had a much bigger idea on our hands than we originally thought, which is usually the case.
If one thing is true of starting a company, it's that no matter how much work you think it will be, it will be more than that. So find ways to keep motivated and keep each other going, because you'll need it. And if you survive long enough, it means you didn't fail. It means you've bought yourself enough time to get it right, and to make something people truly want and love. Something you can be proud of for the rest of your life.
My last point on Dojo is one way I keep motivated and keep going when things don't go according to plan or when problems arise, as they always do.
Take a step back
Stepping back puts things in perspective. It helps you see the forest for the trees, helps expose imbalances in your work habits that aren't sustainable, and helps you truly appreciate what you're building and who you're building it with and for. Taking a step back helps keep you motivated too, which is critical in a startup.
There's something deeply personal about building a startup. For me, I look at it like writing an album or a book. You pour your heart and soul into a startup. You put in unquantifiable hours. You wake up after dreaming of new ideas and go to bed way too late trying to fix one last bug. And it's the nature of software that much of this happens in your head, alone.
In teams, it's something that brings you closer to another person in a way that few things do. Because of the risks and the ups and downs, you're exposed and your character shows to each other. Bad habits can kill startups, and dying startups often kill friendships too as a result. That's another risk you take in a startup. You face uphill battles, substantial difficulty, and that's something that win or lose you share as a team.
Taking a step back has helped me realize what an amazing thing Les and I have accomplished over the past year or so, and as much as it's been hard work it's also been a privilege to work alongside someone like Les and get to know him in this way.
We started out as acquaintances who would sit in the corner and geek out over technology at parties, teamed up on some projects together (Les hooked me up with a few really sweet clients, who have been awesome to work with too!), and then somehow we decided starting a new startup together was the thing to do. Funny how things work out, but taking a step back helps me fully appreciate it all for the amazing experience it's been so far.
I can't recommend starting a company enough - I'm hooked - but make sure that if and hopefully when you do, you step back enough to realize and appreciate the ride.
If you liked this post, make sure you subscribe to our blog by RSS or email so you catch our future posts.
January 18th, 2009 // By les
The upgrade this weekend means several behind-the-scenes improvements that make Dojo a more reliable service than ever. Specifically, these include:
||Hardware virtualization, which means a smooth path for future growth as well as protection from common hardware failures.|
|•||A completely revamped backup system that is much more reliable than the old one.|
|•||Improvements to our outbound email setup, ensuring messages get through to you and your learners.|
||Minor bug fixes that resolve an issue some customers have reported with our custom themes.|
These changes have laid out a strong foundation for future growth of Dojo Learning as well as the basic building blocks for several upcoming new features. We are seeing more activity and more interest in Dojo Learning which is good news for us and you, our customer. We want to grow our company as naturally as we can, and it's happening.
We are also feverishly working on changes to our services based on direct feedback. We know that our customers know what they want and we can't wait to start showing off the many big changes we have coming this year.
Thank you and your learners for helping us grow.
Lux & Les, co-founders of Dojo Learning
January 14th, 2009 // By lux
- New member and learner sign-ups
- Creating and editing lessons
- Chatting and posting to lesson lounges
- Notes, journal entries and journal comments
January 13th, 2009 // By lux
Plan each feature on paper and think it through first
Like I mentioned in the last post, wireframes are a great way to visualize and plan new features out. Each screen of what you're building should be wireframed as best as possible to see how it will flow and to spot flaws in your idea.
This also puts the user first, since you're designing around their experience of your software. A natural extension of this aspect of wireframes is usability testing. You can usability test with just wireframes, before you've written any new code.
We also wireframe mostly on paper. I love tools like OmniGraffle for presenting something professional to a customer, but computer interfaces have yet to even get close to paper and pen in terms of just getting your idea out, and trying multiple iterations and alternatives quickly.
For a good example of how to design a user interface with wireframes, see this paper from 37signals.
Paper is also great because you can write user stories, lists, asides and anything else that helps you get a better idea of what you need to build and who you're building it for.
We also try to get our database schema down at this stage too, since that helps us think about other potential uses for the same data down the road. I find this helps ensure we're not being too limited in our data model, which might hinder future feature additions.
So for us, step one is always designing from the end user's perspective and making sure that comes first. Step two is making sure we've thought of everything from a data and implementation standpoint. From there, the code becomes a matter of connecting the dots.
If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.
December 27th, 2008 // By lux
Don't bite off more than you can chew
We've been developing internally at Dojo a bit like a traditional software project and a bit like a startup. It's much easier to push bug fixes to customers, since you're all on the same system. So bug fixes get fixed much faster, and more easily too since we only have to test against one server platform (although we still have to test in each browser, no escaping that one).
But the quick push model only scales so well for larger change sets, especially ones requiring changes in several areas or changes that need to be made in concert with each other. For those, we've adopted a more traditional "here's what we want to do for the new version, let's do it" top-down approach.
This removes a bit of agility at first, but gives us several benefits. First, we get to announce each major update as a new version. New versions are one of the few things bootstrapped startups can really use to attract attention from the press, so we benefit from that.
Second, it gives us a specific goal that we're working towards, which helps keep us motivated. And third, it gives us a chance to put the whole product into question and ask all those fundamental questions again.
Lastly though, it gives us a finite goal and limits so we don't get into a scope-creep rut or start adding things that are outside of our agreed upon features for that release cycle.
Break things up for easier digestion
You have to break things up into manageable sizes, or you'll end up with chaos, or worse, wasting time on the wrong problems. We try to break things up into the smallest components we can and then plan those out with wireframes, lists of actions, user interactions, database schemas, etc so that we have as clear of an idea of a feature as possible and how to implement it.
It also helps ensure everyone is talking about the same thing, and that you don't mean something different when you're referring to a feature than the rest of the team means.
Once we've broken each feature down into individual wireframes and tasks, those become the to-do list and away we go.
Set a date
We actually work towards specific release dates internally, and while they're not set in stone, they do help us plan how we spend our time and what we can fit into a development cycle. They also force us to think through our features so we don't over-promise and miss the date.
For me, even though I've done the planning and preparations, deadlines still create a bit of uneasiness early on, but once I'm into a groove I find they create a bit of excitement.
The key to realize is that unless you've already begun marketing or advertising efforts around your deadline, it can be adjusted. It's just an artificial date you've set, and pushing it back isn't the end of the world. And it's a good way to get everyone in sync, and to help give the marketing side of things something to plan around too.
If you liked this post, make sure you subscribe to our blog by RSS or email so you catch the rest of this series of posts.