Well I have started hacking on my “next generation LMS” this weekend – I hope to have an early prototype in hand in time for a Monday meeting with the Med school folks. I settled on a framework for the prototype – promise you won’t laugh. JQuery, JSON, PHP, and MySql – yes – I know – so boring. But I can get help from other developers.
And I realized with MySql and the built in PHP5/Apache server on my Apple Laptop – I was nuts to do anything else. I really will miss database portability – for a few minutes :).
So the first part of the weekend is to do some JQuery to build the menu system (isn’t it fun to make really basic stuff at the beginning of a project?). My first reaction to JQuery was “yuck!” – I had seen Prototype in Ruby and loved it – because it did the few things I needed.
When I first saw JQuery, it was like “Where is the simple stuff?” JQuery was a freaking DOM Operating system and all I wanted was a few utility things. And worse – the JQuery documentation does not give simple examples for simple things – the JQ community assumes you are a battle-scarred Javascript guru when you walk in the door.
While the JQ syntax is obtuse, it is far better than the code these gurus wrote previously. For me – I never wrote that complex code – I am just a dummy – I don’t want to learn the nasty way for IE5 and then re-learn the easy JQ way. I just want it easy!
But with a cool mentor like Noah – I get over my mental blocks and get the simple stuff figured out – and once you get the simple stuff working – JQ is a wondrous place. If you wonder how wide the document is, start in Google – look at this page:
http://www.howtocreate.co.uk/tutorials/javascript/browserwindow
Oh yea – who is your Javascript daddy? You need to write case statements within case statements withing case statements. If you are patient and keep googling, you will find this page:
http://plugins.jquery.com/node/1089
A 4K download to find the document width – Better than me writing all the case statements – since the dimensions plugin documentation was not set up for dummies like me – it showed me how to do a million amazing things but not the simple thing I wanted – so I got bored with trying to figure that out – I kept Googling…
And finally I came to this:
alert( $(document).width() );
Uh – this is right there in JQuery 1.2
I can now make my menu dock on the left! Yay!
Note to self: Don’t assume JQuery cannot do something – just keep looking – someone will have blogged a simple JQuery code solution.
The more dummies like me who use JQuery – the more simple examples we will have. Coming up – the simplest JSON / JSONB example you ever saw – I call it the “Missing JQuery tutorial”..
Fixing the Mac Air Audio Plug Design Flaw
Yes – I know – if it was “Designed in Cupertino” – that means that it is perfect and that I should change. Unfortunately Cupertino went through a phase where they decided that the typical headphone/speaker plug was too big – and so they were going to force a new size down folks throats. Given that Apple wants things thinner, lighter and smaller – it made sense.
But the world simply did not change fast enough. The original iPhone and the Mac Air assumed a very small headphone – jack (the diameter of the plastic) around the jack. For a while – I just used my iPhone headset with my Mac Air and conformed to the new Cupertino way.
But as classes started, I was stuck trying to plug my air into the large audio plugs in the lecture rooms and was doomed – I want to make a simple extender cable that has the small diameter male plug and then it is a 3-inch wire ending in a female plug – then I could plug into anything – kind of like those short USB extenders.
But I decided to just fix the design flaw. First I grabbed some wire cutters and cut off most of the aluminum that was in the way just below the audio plug. I cut and bent and got most of the aluminum removed.
This took out most of the aluminum out but left it a little ragged. So the next step was to use masking tape and cover every single opening of the Air (including where the little flip out audio plug was). The *last* thing I needed was little aluminum particles floating around my Air’s innards.


The next step was to grid off the rough edges with a Dremel tool and then use a bit of emery-paper to get them smooth again. Then I blew all the aluminum dust off before removing the tape.


The I removed the tape and viola – I can plug in any audio plug into my mac Air!

Don’t blame me if you zorch you Mac Air with aluminum dust. I was really nervous and careful about the aluminum dust. Your mileage might vary. I do wish Apple would fix this in some upcoming Air – just like they fixed it for the iPhone 3G. Or at least sell the audio extender.
What Language/Framework to use on a brand-new project?
In the next 24 hours I will be starting a new project – a “next generation LMS system” for the UM Medical School – this is a small prototype but I hope it shows the way for how LMS systems will work in the future.
My angst today is what to write it in – and frankly I am still not 100% sure – if you have any suggestions – hurry up – I need to know soon.
Should I use Java?
Java scales and when you have a lot of code – strict interfaces are great. But Java simply means that when you try to build an open source community – you will be ridiculed by hobby programmers for choosing Java because it is too *hard*.
PHP + MySql / LAMP?
Man this is tempting – it works so well – ISP’s make this work for $3 per month trivially. It is really really direct to slap stuff together. And it is nice and relational. It feels so hacky though. Maybe PHP5 makes it feel a little better.
Ruby on Rails?
I love Ruby on Rails – I have never felt so productive in an environment – it is the best way to write elegant code I know of. But it needs to find a hold in the market place. I do not like the feeling of living on the edge and having to become a zealot and sell folks on the framework before I sell them on my product. Last year this time – I put together a small LMS in Ruby – and it was great fun – http://www.rubytoozday.org/. I could even start with that code for my NG project.
Python and App Engine?
Google is behind this – I like that a *lot*. I like Python. I like App Engine’s free accounts. I worry that I cannot scale my service in App Engine yet – there is no pay account and I cannot run App Engine on my own production infrastructure. Oh yeah – and that missing relational database might be a bit of a learning curve. At the same time – in the real world of big-time scalability – sharding is your friend – so why not byte the bullet and force myself to understand sharding.
So on the drive into work this morning – it seemed that even in 2008 – there was no good solution to this problem. DANG!
But as the miles rolled by – I realized that my new application was really about Javascript, JQuery, JSON, REST, and some back end. And I was fussing about what the back-end would be. I already had made much of the decisions of the project without realizing it.
So this makes it less painful to make a choice. Because it is only the headless back end that I am talking about. Even so the back end is an important bit.
So unless I change my mind in the next 24 hours – it will be Python with the following caveats: (a) the real good stuff is isolated into code that does not depend on the App Engine at all, (b) any APIs are defined in REST/JSON and not in Python itself.
The thing that scares me the most is learning sharding under pressure. This is the App Engine risk. I will need to hide my storage behind an abstraction. If I feel too much pain too quickly, I may fall back to PHP or Rails – that will be a harder decision – because Rails is so productive but I don’t have it memorized yet – PHP is a hack but I do have more of PHP and MySql memorized.
Oh the pain of making this decision!
If someone wants to help and/or get involved in this – let me know. I don’t have enough time to do this and I am pretty much a beginner in the technologies I am intending to use (REST, JSON, Javascript, JQuery, and Python App Engine). I guess that is why they call it “life long learning”.
Seriously, if you want to help, I would much appreciate it – I need folks who can really *help* – I do need folks smarter than me who have more time than me. I may be even able to use Med School funds to pay the right person to work on this with me.
Twittering with Trek: SI539 and Python
Trek Glowacki made a cool blog post about the switch of SI539 from Ruby to Python. Trek has been involved with SI539 in various roles for about 2.5 years and he is the smartest Ruby/Rails guy I know.
Here is his post (read this first):
http://wonderfullyflawed.com/2008/09/08/python-for-all-sure-why-not
Here is my response:
Great post Trek. I agree with 90% of it. I am always nervous about changing the world by teaching something that is “better” but not widely accepted. This way SI graduates are unprepared for their jobs when they come out of school – but they are well prepared for advocating for a future state that may or may not happen.
Frankly the switch from Ruby to Python in SI539 was because someone made a comment to me about how useful Ruby was – and I felt kind of bad teaching something with a small market share that was very elegant. But this might be a cool future state: SI502 teaches Python and in a future semester – I teach SI502 more efficiently so I can get some basic App Engine into SI502 – particularly to reinforce the essence of the Request Response cycle and show how the browser and web servers interact to make the “Web”. At that point we could make SI539 move more quickly just switch SI539 back to Ruby and even turn SI539 back to a project course. I assure you that I still have all my Ruby slides in place and with RUby 2.0 maybe SitePoint will keep a book in print for more than 3-4 months :) In this future world – it would be nice to teach Ruby 2.0 and teach it at a high level abstraction that you like. Having the nasty nuts and bolts well in hand having learned the CGI-like world of App Engine – students would be better prepared for the level of abstraction that they would encounter in “Trek’s – Ruby on Rails – The One True Way” :). That all could be really really cool.
We need to solidly teach HTML, basic programming, and the request response cycle in SI502 – and then SI539 could take off from there.
This dialog needs to continue as I am sure it will.
Learning Styles – Warning – Partial Rant
Lots of folks talk about learning styles – and lots of learning software claims to support multiple learning styles – and lots of grants are written and funded to produce material that supports multiple learning styles – etc etc etc.
So I have a really stupid question – as a teacher – I am having real trouble turning all of the learning style talk into clear and coherent guidance for me as to how to alter/improve my teaching to adapt to and support multiple learning styles.
Go and Google “learning styles” – you will find mounds or research on what to name learning styles and lots of pop-psychology web forms that tell you what your learning style is – in one or the other person’s learning style name space.
Try Googling this:
“how to author content for different learning styles”
You will still have to pick through the religious battles about which is the best way to categorize learning styles – or my personal paper about the learning style inventory I came up with – and my survey to check this out – and how I gave this survey to 200 people and wrote a stupid paper about it.
After you get past the myriad of people trying to make their name – the Severance Learning Style Inventory Test! You might find a paper talking about what to *DO* about different learning styles. Google found me this one:
http://www.mrs.org/s_mrs/bin.asp?CID=2725&DID=171663&DOC=FILE.PDF
I can summarize it – give folks some text and give them some animations – and they do better than without the animations – pretty simple and direct – at least we are moving to what to *do* about it.
I got all interested in this because my students are starting to teach me about different learning styles in how they approach my class. And I am finding it really exciting. This may seem crazy – but in a way learning styles kind of remind me of unit tests for software – unit tests remind us to test many paths through our code.
People with different learning styles will take different paths through the material in a course – both the material I provide and the material they can find on their own. I find this out (just like a unit test) – when a student takes an unanticipated path through my course materials and something goes wrong because I assumed one path through the materials and did not compensate for multiple paths. SO when I notice a new path through the materials – I make sure to think about that approach from that point forward.
I always like to give my students a lot of materials – hand out s, screen casts, lecture notes, podcasts of audio – and I let them find their own way through the material. Here is a couple of learning styles I notice:
– Start from the beginning and do everything – this is the way that works well – I made up all the material and sometimes I slide a detail into a screen cast that I forgot to put into the handout and then never go back and improve the hand out – those that skip the screen cast will run into trouble later.
– Start from the assignment and work backwards – look at the assignment – and look at all my materials as possible references to dig through. I am not well set up for this – because there is no good way to search through all of the handouts and video and audio that I produce so the student gets right to what they need – this is kind of the inverted learning style – and frankly a very common learning style in the web/google world – go until you get stuck and then use Google to get you out of a jam.
– Skim through the presented materials as they go by – go to lecture – listen – don’t do any readings – when there is a task to do – the student has a rough idea about what knowledge is where – but needs to go back and dig deeper in the areas that the assignment pulled out. This works pretty well for my courses – students build a lightwiight index as they skim forward and then have their own neural search engine to be able to zero in and find the material they need to know more deeply to make the assignment a success.
Of course this means that assignments must test/touch on the real learning objectives – because that is when all the learning styles kind of come back together – everyone needs to get the assignments done – they will learn at least that much – so the assignment is where you get their attention.
I am going to experiment with these concepts in the course materials I produce from now on – and try to get my students aware of their paths – so they can tell me what works and what does not work and how I can improve.
I am really excited to have the prospect of teaching www.si502.com for a few years with large classes – so I can refine the same material over time and get to the point where I can teach it better and better and be more sensitive to learning styles.
And after a while of course – I will make my own inventory – the Severance-Chuck Learning Style Inventory – write a book and convince Psychology departments to teach it as if it were Maxwell’s equations.
Thoughts on Google Summer of Code 2008
Sakai/IMS had two great students (Kathleen/Jordi) and one student who did not complete the project – this is pretty typical success rate for Google Summer of Code. Leslie Hawthorn – our fearless SOC leader asked the list of mentors how we could better deal with students who did not make the cut by the end of the program. Here is a simplified version of my note to Leslie and the list.
What are your Favorite Features of Sakai?
Charlie Macchia asked: I
Off To College – Amanda
This week my oldest daughter went off to College at Michigan State University (my alma mater) – I stood in the doorway in my robe wishing her luck and hoping the day went well for her. She already graduated from high-school and has a two-year degree and full-time job – so it was a little weird to feel almost as nervous as the day she toddled off into Kindergarten.
After she left I was thinking about how she had chosen her school and the non-trivial part I played in her decision :). She got her two-year degree from Lansing Community College – I love LCC – I went to LCC and I have taught at LCC. LCC is a wonderful place for students to go after High School – it has structure in places and less structure in other places. The advisors and faculty are friendly and caring and the class sizes are small. There is inexpensive covered parking and many of the classes are in the building connected to the parking structure – all in all – a wonderful environment.
As she was finishing up her degree at LCC – the discussion turned to where she should continue her education. She had several places in mind – Ferris State University, Olivet College, and Western seemed like a good fit. She was particularly attracted to the 2+4 programs at Ferris – where they simply came to the LCC campus and taught the courses in the buildings she was already familiar with. Simple and effective – just keep going to the same, comfortable place, and a few years later – poof – out pops a four year degree – slick as a whistle.
She also had a high school friend who went straight to MSU and Amanda had heard horror stories about attending MSU – large classes – distracted instructors – long walks between buildings – expensive parking. So she really did not want to go to MSU – and in particular given the alternative of a few more years in the comfortable LCC building – why bother making it complex? Why take the risk?
But for me – even though I am fascinated with how we will learn “in the future” and the idea that you can take courses anywhere in the world – and do it all using technology at a distance. But somehow – all I could think of in the decision was bricks and mortar – and not just any bricks and mortar – I wanted her to go to the exact same bricks and mortar as I had gone to. Mom got her degree there as well and loved the place too. The physical location mattered – and to me it mattered a lot. The bricks and mortar were my single most important criteria – all of my discussion with Amanda was justifying *why* MSU was her best choice.
So she applied and got accepted to MSU (along with the other places she applied to) – she knew pretty much that once she was accepted to MSU – she was pretty much stuck going there – particularly if she ever wanted to have a conversation with me about college again :) She also knew that if she went to MSU she could get a Red Lobster dinner anytime she liked. She sold out to dad. I picked up her car payment while she goes to MSU. You get the picture… There are many rewards to be had by making dad happy…
So off she went on day one – a little excited and a little scared – and me a little excited and a little scared – you never want to force your child into doing something – they need to live their own life. I was afraid that it would go badly and then I would have been proven wrong – she would drop out and then go back to LCC and get a degree from Ferris.
So why the obsession with bricks and mortar? Probably because for me – going to college has had more impact on my life than anything else. I was the nerd picked last in High School – I had very few friends and never felt I fit in. In college at MSU – pretty much you needed to be smart to get in – so for the first time in my life – I met people like me – and I also met people like me that were more cool than me – so they showed me how I could be a more cool version of myself – without losing who I was.
Sure – I got a degree from MSU – but more importantly I got a personality – an approach to life and a set of life long friends – pretty much I grew up there.
I kept telling Amanda that the most important part of MSU was the people she would meet – the faculty and her fellow students – I told her that in many ways – you don’t pick a profession – it picks you. At a large university like MSU you can meet the future members of a profession and see if you like them. Frankly if you don’t like the kind of people who are in a profession – you should switch professions – and in college is the exact time to figure this out.
So what is necessary is some large and diverse population of bright people – all brought together around some bricks and mortar. Because the community that forms around the teaching and learning will have a far larger impact on your life than the actual material in a course – I know – I have taught college for years!
There is just no way to get this from a degree-in-a-box experience. The problem with a degree-in-the-box is that you are likely to start out pursuing the *completely wrong* degree – if you are stuck churning through the degree – you will never rub shoulders with someone who will show you where your rightful place in the world might be.
I came to MSU to be a Biology Teacher – in an honors Calculus Class I met a guy named Kirk Messmer – he said – “Chuck – you seem kind of bright – you might want to get a student consulting job in the computer center – it is where I work. It is fun and you don’t have to get dirty or clean dishes.” That changed my life forever in a wonderful way.
So as I watched my little girl driving off to school – I hoped that she would find her profession and that her profession would find her. When I wrote that first tuition check – at $1000 per class – it seemed like a bargain – given how much she was going to grow and how she would find her real profession and find her place in the real world as a result – the tuition was a small price to pay. I was paying for bricks and mortar and a learning community and a context – oh yes – some of the money went toward “learning”.
Luckily the first day went very well for her – her teachers were passionate and interesting and a bit nutty (no degree-in-a-box here) the students were interesting and by the end of the first day she was beginning to appreciate the value of something other than degree-in-a-box.
Lunch was a buzz of activity – long lines noise – kids from all over the world – finding their place in the learning community – hearing many languages (no degree-in-a-box here) and watching the Chinese students go around helping each other learn the ropes. In meeting the faculty and fellow students – she already had a strong visceral sense of what career in “K12 Education” is all about. She is excited – even the long walk was not so bad (I neglected to tell her about walking between classes in February).
So we got through the first day without her giving up and running back to the comfortable degree-in-a-box. Hopefully success will breed success and confidence will grow and she will stay at MSU long enough to get student hockey tickets that I can borrow if she does not want to use them!
Commit, Commit, Who Gets Commit?
There is a delightful debate on the dev list about grandfathering in folks with repo-wide commit into K1. Here is my thoughts – it certainly follows in the vein of my rant a few days back. But this post is more reasoned (i.e. less of a rant).
I am a person who ‘lost commit” to a lot of code that I care about, monitor, and work on regularly. I have not asked for commit nor to I intend to ask for commit for those areas in K1 – at least for now.
Given that Ian is very responsive now, and given that I do believe that changes to this most critical bit of our code base need more eyes and more thought than the rest of our code base – I think of not having commit as a *benefit* – not a problem. I wait 1-2 days usually – but as a result I always have a second set of eyes looking at my code and doing a bit of testing of my code and a smart person – looking over my shoulder.
Thinking back to how things worked when this code was spread across the repository and quite a few folks had broad commit – there are several problems that pop out – that are (for the moment) solved in K1:
– Many people got broad commit for some specific task and then we never took it back after the task was complete – often people agreed in the short term to not use their broad power without coordinating with whomever was the lead in the area – but over time they just decided that they knew enough about one or another area to just appint theselves as a committer and start fixing stuff on their own here and there. I remember a time when we would have a discussion about whether someone should have commit to authz – an usually the answer was “yes” – but now – so many people have commit on the whole repo that they get to make the decision about committing to authz them selves. And yes – we are lax about project leads – but frankly it is better to slow down and find a project lead on something than just declare open season with a bunch of repo-wide committers. SO the hypothesis that someone who had repo-wide commit should just get kernel-wide commit is a very bad one IMHO. Perhaps we should revoke a few folks repo-wide commit because their task is completed.
– Some people, (myself included) have commit everywhere because we are SVN administrators – but we never do anything other than what would be called “maintenance” unless we are really part of a project team – things like making branches, changing copyright, etc etc – are very different than fixing/improving code bits here and there. Those people with broad maintainer commit have been pretty good about knowing when not to use their commit. Again – I *technically* can trivially commit to Kernel – but have only done so to change the text of copyrights. Everything else – I go through the lead using the process the lead has asked folks to do.
– We have a number of different technical opinions about the overall direction of our code base and approach – we have competing architectural ideas and we have some pretty strong disagreements between some of our lead technical people. Far too often these conversations reach an “agree to disagree point” and when the conversation is between two committers with repo-wide powers – the two folks just start doing “both” things in the repo and trying to gain customers to “their way” of thinking over time – they get their particular approach into folks dependencies and then they can slowly win the day – frankly what happens is that we never get back to one solution – we just end up with two way of doing something for ever and lame compatibility between the two approaches over time. Our core architecture gets less and less clean as we have many approaches scattered across the SVN – each with a different level of maturity and different resources applied to them – and little cliques forming around approach X or approach Y – slowly splitting our thinking. Instead of working through the debate – folks with repo-wide commit just put the code in the repo and let us all figure it out. This is not a good approach to the most core bits of our code base.
I just think that it is a good idea for folks to have to justify their idea to a review team at a minimum before they just get to drop something into the kernel.
I guess the simplest formulation is this: Before K1 – if people disagreed with Ian on how something should happen – they could just say “piss-off” and commit the code that they wanted. After K1 – people who disagree with Ian do not have the alternative of just committing their opinions to the SVN and bypassing him.
So if you are advocating giving kernel-wide commit to all the folks with sakai-wide commit – what you are saying is that you want a continuation of anarchy in our approach to technical direction for the core code base – you are making sure we continue to be able to make major changes in technical direction with absolutely no review – if a person with svn wide commit feels strongly about some technical direction for Sakai in the morning – by evening – whether we know it or not, we are all stuck going in that direction.
I am sure that the folks who want this commit are the folks who have disagreed with Ian over the years – these folks are all smart folks and they have great ideas – and yes some chaotic organic improvement can be a good thing – but do you want chaotic improvement in the kernel??? Do we want the chaotic approach at this point in Sakai 2.x code base? Do you want to have alternative technical approaches explored in the code base and in your production instances? My feeling from the broad community (not the core 10 bright folks with great ideas) is that people want stability – not continuous change in our source tree.
This is where folks keep saying – “move the creative energy” to K2 – get involved – dig in – and fight things through with a group of people where we can try two alternatives as an experiment and then pick the best one without messing up production and a whole library of contrib developers – and a bunch of vendor branches.
The current K1 approaches insures that a technical disagreement will remain a disagreement until it has been discussed long enough and by enough people to make a community wide decision.
I am sure that folks will bring up the “I have a lot of bugs that need fixing” argument – for me that is not a good argument – bug fixing is *easily* done with patches – and a forced code review step is a great thing for bug fixing – and a great idea for the long term health of the code.
I know we want more unit tests – so perhaps the commit access to the unit test are should be opened up a bit – to folks who can make a long-term commitment to writing *and* maintaining all of the unit tests. This seems like a legitimate request – but getting commit in one area does not give one commit everywhere – folks can “ask for this commit” and when there seems to be long-term commitment to the code area in question – then commit can be granted.
Another excuse that folks want broad commit is “everything in Sakai’s current code base sucks – and I am here to find and fix all the suckiness wherever the suckiness is hiding – and given that I have a very small amount of time – I cannot afford to do anything other than committing the fixes to the sucky bits right to the code base”. This statement is wrong on its face – Sakai certainly has room for improvement in lots of places – but at the same time – what we have mostly works solidly and at scale. Those people who do not respect the value in the current code base – are *not* the people you want fixing it – because they don’t respect what is there – they don’t even bother to figure out what something does before “fixing it” – and then they will be off to the next sucky thing that pops into their mind and go “fix” that.
Everyone brings up “Apache” as the inspiration for this approach – actually this is somewhat un-Apache like. For simple projects like Pluto, generally when you are accepted as a committer – you get full commit to the whole source base. Common sense and community culture keeps you from doing stupid things in places you should not touch and as things evolve – perhaps you become the technical lead this time next year – you end up committing all over the place or even trigger a major refactor that you lead.
The reason that this works is that Apache has ways to resolve technical disagreements – strong disagreements are allowed in Apache and these disagreements are worked through in discussion to a resolution – these discussions are allowed to get heated and intense when necessary. If someone loses, they either get on board or (rarely) to fork the whole project (this happened in Pluto). When the person is so sure that they are right but lost the argument – they fork the whole code base – this way they are taking responsibility for *everything* – not just the little are they care about – this way they will learn the full impact of their decision before *anyone else* is affected. Some forks die – some forks live. My guess is that the most common case is that the person starts playing in the fork – realizes they took on a lot of responsibility and then comes grudgingly back into the fold – folks had choices – and with enough effort they could force their choice – and when their branch works – they are the new technical lead for a while – and everyone starts bitching at them :)
Our problem is that we never resolve the discussion and we never make a “fork” – the person who loses the argument – just uses their “svn-wide commit” to slide their alternative solution into the common code base – and all of our users, developers, and system admns are stuck with yet another confusing and inconsistent approach.
I have talked too long (as usual) – we need to slow things down in K1 – we need to stabilize the core bits of sour source base – the 2.X line needs to move toward “enterprise thinking”. Innovation and fixing the “perceived ills of Sakai” need to be done in K2.
Switching to K1 is an opportunity to bring a bit of discipline to ourselves that we are sadly lacking. Lets not throw that out immediately – lets see if we can make it work.
Interestingly this very argument is a place-holder for all those technical arguments – one group is advocating for a calm, conservative approach and the other group wants freedom to directly implement their ideas in the code base. As a developer – I like the idea of causing change through commit access – but as a community leader – trying to represent the broader stakeholder interests – I understand the need for limitations on my own actions – I understand that may I need some review before I go in and re-do some bit of kernel based on a brilliant idea I had in the shower this morning. And maybe the answer to my brilliant idea should be “no” – or perhaps the answer needs to be “next summer”.
P.S. If it gets to the point where Ian and his folk take more than about a week to apply my trivial patches – I will join the clamor to get commit for me. But for now with Ian responding super-fast – I am loving the new process.
Reading Usability Book: Don’t Make Me Think – Steve Krug
I was digging through a pile of old stuff with a friend throwing away things which were no longer needed and came across the usability book Don’t Make Me Think written by Steve Krug in 2000. It was pretty thin and I had to wait for an oil change and some tires being installed so I started reading it.
I really like the book – it speaks to me and explains usability issues in a ways that make sense to me. Perhaps the reason I like it is that it was written in 2000 and my understanding of web technology is somewhere back in 1997-1998 so this is something I am capable of learning :)
Steve keeps it simple and gives some basic mantras that I find pretty easy to apply now when I am designing something. I particularly like that he does not try to make Usability something mysterious and complex and only best done by experts.
I now walk around and apply his “Don’t Make Me Think!” mantra all the time. Yesterday I was at Office Max buying some ink-jet refills. I knew my printer model and even knew the in “family” called “Epson Claria” – but when I got there, there seemed to be two cartridge series that were for my printer – so I wanted to verify which printer the cartridges were for.
Without thinking I picked up a box and looked at the back and sides of the box – looking for some fine print (black on white background) telling me which printers the cartridges applied. As Steve would say, we parse new situations using the rules we have learned form the old situations – when things “fit the mold” folks can use the new design *without thinking*.
When I did not find what I was looking for I was forced to think – yikes. Now I was in trouble. SO next I looked for a book of specifications – the other vendors had a book hanging at a particular location on the shelves – but for the Epson shelves – no book! Aargh – more thinking.
So next I saw the helpful sales person – she came over and I had to admit that I (A computer science PhD) could not figure out how to pick ink for an RX580! She took the box from my trembling hand and pointed out that the ink I was indeed suitable for the RX580.
The fine print was on the *top* of the box – it was small print – it was white on a blue background – and it violated the Steve Krug Home page rule – it was buried under two lines of “Happy Talk” (one of Steve’s rules is “Happy Talk must die”). It told me in English and French that there were five cartridges in the box – AAARGH – the box was 3.5 inches deep – OF COURSE it had five cartridges. I made a special trip to this store intending to buy five ink cartridges! AARGH. Another Steve rule is not to waste space repeating what the user already knows.
And it violated another Steve rule making the important data the largest font. The “how many cartridges” lines were larger font than the printer line. The printer list was in bold so they did get one thing right. The number 5 was very large and also in bold and it was the first thing you see when you look at the box top.
Of course my mind runs to the design meeting where they decided that putting the stuff on the top of the box was the best approach:
– It means folks can figure out which printers a box of ink applied to without touching the box
– And with the above improvement – we no longer need a box of ink cartridge applications – saving the company far more than the designer’s consulting fee
But – by making several simple mistakes, the decision made me think. Luckily I am capable of thinking and did successfully get my ink cartridges.
The right way to do it would be to put the cartridge applications both on the top and on the back in black-on-white print. Then I might have learned the new way – but also if I did it the old way – it would have worked. Another alternative would be to make the top of the box white and only put the printer list and none of the happy talk.
Now my mind is racing on the redesign of www.dr-chuck.com…
But the real upshot is that now I think of myself as a qualified UI expert because I read a book written in 2000 while getting my oil changed and tires changed.
Or at least I know enough to be dangerous to myself. I am looking forward to reading the whole book sometime. A transmission service should do the trick.