These are some thoughts that <a
href=”http://www.branimir.com”>Branimir Dolicki and <a
href=”/lars”>I, generated while developing Knowledge Management
for Siemens. I hope to one day put reality behind all this and see how
it works in real life.
The huge picture
What is “knowledge sharing” or “knowledge management” (km) anyway?
It’s basically people teaching each others. So a km system must
ultimately be built on ideas of how people learn best. Since some
people are better teachers than others, we will want ways to help
users improve their teaching skills.
Why do we want to share knowledge? We assume reasonably that having
people teach and inspire each other, each individual will grow
personally by both the learning and the teaching. The company will
benefit directly from more knowledgable and inspired workers, and
indirectly by avoiding duplication of efforts.
What is knowledge anyway? Without getting too philosophical, it’s
basically information that can be put to use. So we want to help and
encourage people to express themselves in ways that are of use to
other people. In other words, to put themselves in their reader’s
place. This is something software can never do by itself.
The management task
Sharing knowledge is not something that will be achieved by software
alone. Software can facilitate things but it cannot overcome
organizational and personal obstacles. If employees are rewarded for
being the only person possessing certain knowledge, there will never
be be much knowledge sharing going on. So we must make sure we
reward good teachers.
The big idea
We want to encourage users to contribute by making it easy and
imposing very few restrictions on the content. If the user feels like
sharing something, it’s probably important to her, and she probably
knows best how to structure her idea. It might not always be the case,
but we need editors and other people, not software, to help users
become better teachers and writers.
To avoid stupid postings taking up thousands of people’s times, we
make tools available for estimating the quality of an entry, and to
rank and sort by this estimated quality on every list of entries ever
shown.
We obviously want to let people browse the knowledge base by
categories and do full-text search.
How it could work
The basis is text. Users can write a piece of text that they want to
share with other users, be it everyone, registered users, a predefined
group of users, a specific list of users or none at all
(private). It’s just a simple HTML fragment, anything from one line to
a chapter of a book, full text indexed, and can possibly have attached
files. We keep all versions of entries and files.
To help users link the knowledge base, we offer a very simple way to
link to another entry, e.g. by just saying [other-entry-key], which is
then translated into a real link when the entry is inserted into the
database.
To help users find information, the entries can be categorized in
multiple categories. The author can suggest categories to put it in,
as well as new categories altogether. The administrator can (if he so
desires) approve both categorization of an entry and new categories.
To help users prioritize, entries are rated, both explicitly and
implicitly (“votes”). Users can explicitly rate an entry on a scale
from 0-3, 0-5 or a similarly small set of rates; we don’t really trust
explicit rates, since people tend to be lazy at rating, and only gives
either top or bottom rates. Thus explicit votes have a low
weight. Users can choose to send an entry to another user (“send this
to a friend”); we give this form of vote a high weight. We also track
how many users have read a particular entry more than once, and count
that as a vote for that entry. We count a link to another entry as a
vote for that entry.
We also rate the users. A vote for an entry is also a vote for the
author. The more highly appreciated the author is, the more his votes
count. We help users evaluate authors and voters by letting them see
contents contributed by each other’s, possibly including their overall
rating.
To help users explore the knowledge base, we offer links to related
items by categories, and by “users who liked to this entry also liked
to …”, preferably giving priority to entries the user hasn’t seen
before.
To support collaboration, users can comment on entries, and authors
can let other users in as co-authors. Comments on an old version are
marked as such with a link to the version they’re commenting on.
We might need a way to hide a comment from the default page in case
the author takes the comment seriously and changes his entry.
To support the evolution of the knowledge base, an entry can be marked
as deprecated by the author or the administrator. A deprecated entry
can be taken over by another entry, which is then the current (“this
entry has been succeeded by this entry”).
There are two seperate and equally important parts to being a great
programmer. You need absolute technical mastering of the technologies
you use. But that’s the easy and boring part. The hard part is
designing software so that it’s useful to the people using it.
I’ll present a lot of stuff here. Don’t be overwhelmed! You don’t have
to learn everything at once. You don’t even have to learn everything I
say here at all. But it does help to have some sense of direction in
your adventures. That’s what I am trying to pass on.
Note: A hacker is a programmer. A cracker is a criminal.
The important part
Start right away by reading Alan Cooper’s
The Inmates are Running the
Asylum
and
Philip and Alex’ Guide to Web Publishing.
important books about how to design software today (they are, at
least, to me). Cooper’s book is about software design in
general. Philip’s book is focused on web programming and includes
technical stuff. They’re both great eye-openers.
These are perhaps the two most
The bottom line is that you should focus on what the users of your
software want to accomplish. Think as hard as possible about real
users and their real needs, how you can anticipate and support
them. Work hard to make the software and the computer work hard to
help the users do what they want to do with as little effort and
cognitive friction as possible. Help users in ways they never thought
possible.
“No matter how cool you user interface, it was better if there were
less of it” (Alan Cooper, About Face). Users don’t want to learn your
user interface. They want to get a job done. You must know what job
that is, what it takes, what the use situation is like, what the user
is like. There is no substitute for knowing what goes through the
user’s mind. This isn’t something that can be formalized. It takes
empathy. You’ve got to be out there with her. See it with your users
eyes.
When programmers face a design decision, the gut reaction is to
refrain from making the choice and putting the burden on the user
instead. Take use of screen real estate as an example. When
programmers don’t know how to make best use of the user’s screen real
estate, the gut reaction is to say “Oh well, we’ll just provide him a
completely general mechanism to place all tool bars and menus
arbitrarily and to redesign all menus and toolbars”. How many users do
you know that does that with their MS Word? How many users you know
have placed their Windows task bar anywhere else than along the bottom
of the screen? None. Is that because everyone’s satisfied? No. The
user still find the overuse of screen real estate annoying and
wasteful, but spending time moving and rearranging toolbars is even
more painful. It solves the wrong problem.
If your software needs a printed manual or a context-sensitive help
system to use, you should go back to the drawing board and rethink it.
I’m not saying you shouldn’t help your user. But contrary to
mechanical items, computer software have the ability to explain
themselves without breaking the flow. Help the user when
necessary. Record relevant user behavior, learn as much as possible
about the user, and let the software adapt itself to the user and the
user’s situation. Don’t present options that aren’t relevant to the
user.
The part that users couldn’t care less about
Now to the techinical part. It may sound like a lot, and of course it
will take some time. But you’ll discover along the way, that it really
is quite simple, if you take it one step at a time. You’ve probably
been brought up to simultaneously think computers are easy (the
Windows desktop) and at the same time immensely hard (troubleshooting
the Windows desktop). But with the right tools and the right approach,
you’ll hear yourself going “Whow! Is that all there is to it?!” over
and over again.
For an example of that, try running
telnet www.amazon.com 80
in a Linux shell. Telnet will reply by saying
Trying 208.202.218.15...
Connected to www.amazon.com.
Escape character is '^]'.
Then write
GET / HTTP/1.0
followed by two returns, and watch what happens:
HTTP/1.1 302 Found
Date: Fri, 21 Jan 2000 09:41:59 GMT
Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)
Location: http://www.amazon.com:80/exec/obidos/subst/home/home.html
Connection: close
Content-Type: text/html
followed by some HTML. Congratulations!
You’ve just learned the basics of the HTTP protocol.
First step is to ditch everything with Microsoft’s name on it. Not
because Microsoft is evil. But because Microsoft’s key vision is to
shield users (including programmers) from the underlying
technology. End users should be shielded from irrelevant technological
aspects by designing software based on actual knowledge of the users
and the use situation. Progammers should never be shielded from
technology, because inevitably the programmer will run into some bug
that can’t be solved on the upper, abstracted layer.
Install Linux on your Intel box. Not because Linux is the perfect
operating system, but it’s one of the better, and it has a lot going
for it. Take the time to learn to master all the command line utils
and the inner workings, like configuration files and interaction
between processes. Learn to master Emacs, the number one application
you’ll be using. If you have a non-english keyboard, set it up, so the
keys work like on a US keyboard. In the US keyboard setup, often used
keys like <, >, [, ], {, }, /, |, \, ;, :, @, $, #, ”, ’, =, _,
?, etc., are placed so they’re much more easy to use.
Virtually every interesting computer program today is centered around
networking, so you should also know about basic internet plumbing and
learn key internet protocols, like TCP/IP, DNS, SMTP, HTTP. You don’t
have to know everything about them, but you should have a solid idea
of how they work and interact, so you can troubleshoot and learn more
along the way. Key network command line utils like ssh, scp, wget,
telnet, traceroute, whois and nslookup are also a necessity.
Along the same lines, you should seriously consider investing in a
real internet connection. It’s still relatively expensive but just as
a networked computer is a hundred times more useful than a standalone
computer, an always-on internet connection is a hundred times more
useful than a dial-up. No more annoying on-line/off-line
dichotomy. The physical location of hardware, software and data
becomes irrelevant.
Printing is outdated, so who needs word processors. Learn how to write
casually in HTML by hand using Emacs, and use that for all your
documents. If you really need printing, you can print from a browser.
If you really need control over layout, you can learn LaTeX, which
translates into Postscript, which in turn translates into a PDF.
If you’re going to build applications to support business, you’ll
inevitably be using a RDBMS. Download free (for development) Oracle
for Linux and learn how to do SQL and PL/SQL. Learn enough about
administering to be able to troubleshoot and learn more as the need
shows.
Programming languages are irrelevant. Which is why you should be
familiar with at least ten and be able to do real programming in at
least five. When you’ve reached that limit, you’ll realize that
they’re all basically alike (they’re all turing machine capable), and
you’ll be able to quickly determine which language is right for the
job. Good candidates for languages to learn are C (but pray you’ll
never have to use it), Java, Lisp, Tcl and bash scripts.
Integrated Development Environments
“But isn’t this business of hacking plain text files using an editor
old-fashioned, now that we have visual development environments?” I
hear you ask. No. Visual or integrated development environments like
Visual Basic or Delphi solve the wrong problem. They assume that
moving widgets around the screen with a mouse is easier than writing
text in a text editor. And to a first approximation it is. But the
visual environment shield you from what happens under the hood. If
you’re a programmer you want to know what goes on under the
hood. Eventually you’ll run into a bug where the upper layer doesn’t
work as you expected. When that happens, there’s no alternative to
debugging the actual code being executed, which is inevitably plain
text source code. If you’re already familiar with that, you’ll find
the bug much quicker.
What’s more important is that plain text files are easy to
manipulate. Once you’ve learned the language in question, it’s much
faster to use your favorite text editor (Emacs) to write the code by
hand than drag widgets around the screen. Besides, there are a
gazillion of tools that can do interesting things to plain text
files. And writing up your own text-manipulating program is
ridiculously simple. It’s easy to use grep to find every use of a
specific function. It’s easy to use cvs for version control. It’s easy
to edit remotely through a secure shell. If the source code is pure
text, it’s easy to write a program that will output source code.
HTML is just plain text. That’s why it’s so easy to write a program
that will output HTML. Bingo! You have a dynamic web site. SQL is just
plain text, so it’s easy to write a program that will output SQL
statements. There you go! You have a program that can do flexible
queries in the database. If you really think you need a desktop user
interface, there are programs that given a textual description in XML
will produce the code that implement your GUI. Thus you can write a
program that given a high-level description will produce the XML
files, then translate those XML files into the actual code. That’s
powerful.
Plain text files will never go out of fashion. They’re easy for humans
to read and understand (as opposed to binary files), and they’re easy
for computer to parse. Admittedly, a program operating on a carefully
engineered binary format may perform slightly quicker. But programs
are not primarily written for computers to execute. Programs should be
written primarily for programmers to read and understand. Thanks to
Microsoft’s CPU-consuming bloatware, Intel-processors are now so
powerful and cheap that the performance loss is negligable. Programmer
time is much more expensive than processor time.
I’ve experienced so-called programmers, living in a shielded world,
that could spend a whole day figuring out how to manipulate the
pathetic API of their bloatware of choice to do something as simple as
select user_id from users where user_name=’larspind’. And
to top that, he’d even, seriously, claim that the reason it was so
hard, was because “in (product name) it’s so easy,” you can only use
the functions they’ve decided to provide to you!
