By law of nature, I make notes during such a day. I didn’t, however, make a full summary; so I can only give an impression with a couple of loose remarks and quotes and ideas.
Anyway, the day was bits of theory interspersed with group exercises, culminating in a design that we tested with paper prototypes. To start off I’ve got a video of those tests. (If you don’t understand Dutch: scroll through to the 1 minute mark. That way you at least get a nice impression on how a paper prototype can work.)
A core idea is mental modeling. What is the mental model of the user? What mental model should he have in order to use your app or website? What mental model of reality does the user already have? Which terms or concepts should you use in your app or site?
Interviews are important to get this clear. And if you interview or if you observe someone: listen. Listen a lot. At least initially. You are the student, the user is the teacher. Take time to gain trust. And when you do ask questions, try to get to the bottom. The user might say something, but after asking “why” five times, digging ever deeper, you might get a different answer than originally. Alternatively, use the why/where/what/when/who kind of questions.
Why are mental models important? Well, you make them anyway when interacting. Enter a building and you see the door knob: you automatically make a mental model of that door knob and the way you expect it to behave when you interact with it. Should I push or pull or whatever?
So when your site or application has a good and consistent mental model behind it, it will provide you and your user with something to hold on to: it helps you explain what happens and it helps you understand what happened and what is about to happen when you interact with it.
A very good requirement you can force upon yourself when you make a mental model: you should be able to explain it to your grandma within two minutes.
Tell stories. Human beings like and relate to stories. So write down textual usage scenarios (or visual: simple comic strip). Use specific thought-up “personas” like “Harry from accounting who positively hates computers”. And try to get together a representative number of usage scenarios.
Those scenarios, when written down, help get discussion underway. If you only tell what you’re going to do, it is easy to nod your head and to agree. If you see something written down that’s obviously wrong or obviously missing key elements... Discussion! This way you gain clarity quickly. And... you gain clarity before spending four weeks programming something!
After gaining clarity in this way, the next step is classification. Basically: find the right words. Nouns and verbs. The terminology you use for your application. Spend time getting this right.
Btw, make a difference between information structure and application structure. The information structure means the content. “Article”, “blog post”, “map layer”. So: the core data structure. The application structure, on the other hand, is much more about about the form/layout.
(Note: he mentioned the elements of user experience by Garrett (link to PDF with the main graph). The way I understand it now as I can actually read the graph is that the information structure/application structure difference is more of a “duality” that needs to be resolved in the resulting visual design.)
Conceptual design is the next phase: design the main structure of your website. Items like:
So basically: converting the output of the classification/terminology phase to a navigation. Tip: make wireframes or mock-ups of the various screens and draw the navigation (the flow) between those wireframes. He called it a wireflow.
Apparently designing interfaces by Jenifer Tidwell is “the bible” for stuff like this.
When designing, use four Gestalt principles: proximity, similarity, continuity and closure. (The page linked has five items, btw).
And keep in mind that too many choices mean that a task takes too much time (Hick’s law), so don’t put in too many choices.
As scientists predict a wetter, stormier future for much of the planet, the Dutch have become a nationwide consulting company, fanning across the world to talk about water.
I’m reasonably well-known as a Python developer (and zope/plone/django). So what am I doing here in a water company? Nelen & Schuurmans is one of those water consultancy companies mentioned in the article. The reason for my presence is also right there in the article:
“The Netherlands is very conservative. We think we can solve everything with a bit of sand,” says Jan-Maarten Verbree, who heads IT at Nelen & Schuurmans, the water-focused consultancy behind 3Di. “But we say that with a bit of IT, you can increase safety even more.”
IT and consultancy go hand-in-hand for us. Which gives nice results as the company is really smart: almost everyone has a university degree (with a couple of PhDs thrown in). Trying novel approaches. Combining ideas. Combining fields of work. Combining fields of experience.
Personally, I’ve got this combination right here inside myself. I’m a Python developer. And by education I’m a civil engineer. Two side notes:
So by education and experience (and importantly: interest!) I fit right in. There’s a lot of freedom that I also enjoy a lot. And we’re profitable, which is quite a feat in the current marketplace (and quite good for not worrying). A funny quote in the article points at one of the reasons for the profitability: we don’t spend a lot of money on unnecessarily decorative offices.
In the Nelen & Schuurmans lab, a Spartan collection of desks located in a house in the medieval heart of Utrecht, ...
We are however dead smack right in the center of Utrecht, which is a lovely place to have an office!
Note: as I’m spending quite some time muttering right now (over a technical decision), truthfulness forces me to say that not everything is roses and sunshine. But that’s something for a separate entry (probably on how I try to deal with it, I do have to re-gain my positive energy).
I’ve got an iPhone 4S and I recently updated to iOS7.
One problem I noticed: the battery would drain faster. Way faster, in some cases. I think the cause is the “background app refresh” in combination with a couple of GPS-using tracker apps (strava, runkeeper, cyclemeter). I’ve been experimenting with them and when you give them the background permission (which they really need) they all seem to stay running and guzzling up your battery with their GPS, even when not recording.
At least, it seems like that. Likewise several other apps seem to work better with background app refresh, but they also use GPS. Some tweaks I made:
I hope that keeps the battery in check a bit. Perhaps I ought to switch off some more items: my battery is at 92% now. Seems a bit quicker that it used to be. Any more tips?
A bit of a delayed entry... I switched from glasses to contact lenses in 2009 and wrote a couple of blog entries about my experiences.
However: after about two years I switched back to glasses. (I did say this entry was a tad delayed). Here are some comments:
The main reason was money. Twice a year you need a new package of six pairs of month lenses. Quite costly. Less than glasses, but the cost is recurring. And don’t forget the cleaning fluid. After two years I had the idea I had paid the same sum I’d otherwise had paid for glasses. Time to switch.
The most direct reason was an accident. A few weeks before it happened I had problems getting a lens out. It had shifted a bit to the side and got dry and stuck to my eye.
The real accident was that my right eye’s lens wasn’t sitting right. That lens had a cylinder, so my vision would be no-lens-in bad when it was rotated upside down. It dropped when taking it out and putting it in again. Without me noticing it. Ah, it is upside down (I thought) and tried for 15 minutes to peel my own eye out. Until I spotted the lens lying near the sink in the bathroom. That little episode did not feel safe.
Oh, how wonderful it is to just put your glasses on your desk in the evening and pop them up again in the morning. It takes a second (instead of one or two minutes with glasses). To me, this was a bigger advantage than expected. Nice.
Anyway... I’ll stick with glasses for the rest of my life, I guess :-)
What??? Look at https://www.writelatex.com/ . Online LaTeX editing with live preview.
I’ve done quite some LaTeX’ing in my life. I never suspected anyone would create a web editor for it. Good idea, though! Even collaboratively editing the same document works (I tested it with my brother). Nice. See the resulting pdf or the read-only online version.
Pillow is a better-packaged version of PIL, the Python Imaging Library. There’s one problem you can see, though, and that’s with importing. PIL allowed both import Image and from PIL import Image. Pillow sanely only supports the second version.
A colleague had a problem earlier today with TileStache that used the old import Image version. And that fails with Pillow. The solution I suggested him was to add a little hack at the top of a file that’s loaded early in the process (in this case a Django settings file was the best spot):
import sys from PIL import Image sys.modules['Image'] = Image
This makes sure you get PIL.Image when you do import Image afterwards. Problem solved.
Note: if both of the imports work for you without this hack, it can be a good idea to check if you need to clean something up. Import both versions and check their __file__ attribute:
>>> from PIL import Image >>> Image.__file__ '/usr/lib/python2.7/dist-packages/PIL/Image.pyc' >>> import Image >>> Image.__file__ '/usr/lib/python2.7/dist-packages/PIL/Image.pyc'
In my case, I only have PIL, apparently. The colleague had a different result for the first import: that one was from Pillow, the second from PIL. Something to keep in mind if you have weird PIL-related results.
I’ve updated my iphone and ipad to Apple’s latest iOS release. Some thoughts:
So... Happy with the upgrade!
I noticed a question on stackoverflow about Fabric + buildout as opposed to Fabric + pip + virtualenv. Good question! Why? Because Fabric changes the regular trade-off between buildout and pip:
“A lot more” includes things like configuring supervisor, generating an apache file, creating directories and so. Either you automate it so that buildout does it for you or you hope that your colleague reads the README and actually does everything that needs doing before complaining to you that “it doesn’t work”.
Fabric is also used for automation. The things you’d put into your fabfile.py to set up your production environment on the server, those very same things you can of course run locally. So a bin/fab setup_local_machine could take the place of “read the readme, please, after you’ve run pip”. Which could take away some of the need for buildout.
My suggestion: look on pypi for buildout recipes to see if they are handy for you. Do they save you enough work to make it worthwhile to dive into the extra complexity that a full buildout configuration means? There’s a lot that can be done for you for free. Do you really want to re-invent the wheel by hand in a custom fabfile.py?
If you can do it quickly with a fabfile, there might be no need to look at buildout. Anyway: take a look!
Note: I’m using both fabric and buildout. Buildout sets up everything I can get it to set up. I use fabric to do the git checkout of the buildout and restarting nginx and so: everything outside of buildout’s control.
(Btw, I’ve answered the question, too).
I recently did quite some work on the syseggrecipe buildout recipe. It makes it easy and reliable to use packages that are installed globally, for instance by Ubuntu.
Buildout is great for repeatable builds of Python packages. It grabs a bunch of packages off Pypi (the Python package index) and you’re done. Pure Python packages are no problem. But sometimes there are packages that are a bit harder.
Some packages require quite a number of libraries to be available, preferrably as development packages. In Debian/Ubuntu terms, this are the *-dev packages. These packages contain C code or build upon existing libraries. All in all, this is sometimes functionality that’s better provided through your OS. Who wants to build “numpy” by hand? Way nicer to just do an aptitude install python-numpy and to automatically get all the dependencies.
The syseggrecipe buildout recipe provides a handy way to re-use those perfectly packaged “system eggs”. They are already there, so why not use them? We know that buildout is best used to gather everything together on its own, but there are practical limits. Sometimes system eggs are handier.
The syseggrecipe recipe allows you to specify which eggs you want to grab from your OS and it injects just those eggs into your buildout so that you can use them without pulling in everything that’s on your system path.
An example of how to use the recipe. Please note that the sysegg recipe must be the first buildout part to make sure it gets the first go at grabbing global eggs.:
[buildout] parts = sysegg [sysegg] recipe = syseggrecipe eggs = netCDF4
To stop the buildout when not all syseggs are installed include: force-sysegg = true:
[buildout] parts = sysegg [sysegg] recipe = syseggrecipe force-sysegg = true eggs = netCDF4
This way, the specified eggs must be installed globally. Otherwise they are optional (which might be a fine choice, too).
The core of the system is buildout’s concept of “development eggs”. This is a special directory (``develop-eggs/’’ within your buildout) with pointers to Python packages that are currently being developed. These pointers take precedense over any other item. Examples include the project you’re working on, but also items you installed with mr.developer.
For every egg specified in the part, setuptools is asked for a matching distribution. If one is found, it is inserted into the develop eggs directory. There are two ways:
Both ways are enough for setuptools to know the global egg exists. As buildout doesn’t strip out the system path (except for the abortive 1.5/1.6/1/7 releases), setuptools can find them globally. We just had to make sure it knows how to find them.
So... Try it out and see if it works for you. Note: due to the symlink, it doesn’t work on Windows.
Yesterday I attended a Dutch “google developer group NL” meeting about AngularJS. I expected to get a couple of solid technical talks about AngularJS. And a meeting that was more or less on par with a Python/Django meeting.
What I got was:
Oh shit. I’m gonna kick the colleague that suggested the meeting to us (but who strategically couldn’t make it to the meeting...) in the nuts the next time I see him, I guess. What didn’t help is that there was drenching rain during the evening so that I was totally soaked when I got there and that I was still cold by the time I got home.
Now, what do you get on a typical python/django meeting in the Netherlands?
So... never ever am I going to waste another minute on a Google Developer Group NL meeting. Especially when it is raining.
Statistics: charts of posts per year and per month.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):