Some thoughts on Django and usability
James Bennett
more productive discourse to be wrung from it, so let's start anew.
What follows is my own rambling personal opinion, and nothing more.
One of the issues that seems to have come up from the "audit" thread
is that of the usability of Django. There are a lot of solid general
usability guidelines, but there's one that reigns above all, the
uber-guideline if you will:
Know your audience.
It's a simple truth that you can't please all of the people all of the
time, so at some point in any development process you have to sit down
and mark out three groups:
* The people you have to please to stay viable
* The people you'd like to please, but won't necessarily bend over backwards for
* The people you won't make any accomodations for at all
Having that last group probably sounds awful, but consider what
happens if you don't demarcate them: in Django's case, someone might
well come along who doesn't even know what the Web is, let alone a web
site, web application or web framework. How would Django accomodate
that person?
The answer: we can't, and trying to is a waste of time which diverts
attention from our core concern, which is looking after the people in
the first (and, to a lesser extent, the second) group listed above.
So in terms of Django, here's how I see the groups break down:
* The people we absolutely have to please: actual web developers,
where by "web developers" I mean people who know at least one
programming language, understand at least the basics of relational
databases, and have written a significant part of the backend code for
at least one dynamic, database-driven web application.
* The people we'd like to please: less experienced developers, and web
designers who may or may not know anything about programming but who'd
like to learn.
* The people we won't make any accomodations for: anyone not in the
above two groups. Trying to get someone up to speed who's not a web
designer or developer of any sort is a task that's not really
compatible with providing a high-powered tool for more experienced
users. If they can pick up Django and use it, that's great, but if
they can't we shouldn't be losing sleep over it.
The next question is how far we should be willing to accomodate the
people in the second group, and the answer is simple: as far as we can
go without inconveniencing the people in the first group. Let's look
at a concrete example proposed in the audit thread: automatically
setting up a SQLite database when a project is started, and installing
the admin app into it.
This would, probably, offer some benefit to novice developers, because
it's a couple less things they have to do at the outset (though it
arguably adds in some "magic" that it's better to have them
understand). But it offers zero benefit to experienced developers and,
most likely, would hinder them: they're going to want to develop on
something resembling their production environment, which means
probably MySQL or PostgreSQL (maybe even Oracle once the adapter for
it stabilizes sufficiently), and there's no guarantee that they'll
want to use the admin app -- there are plenty of uses for Django that
don't involve the admin at all. So this gets in their way and detracts
from the out-of-the-box usability of Django for its core audience.
Thus, this proposal should probably be rejected.
Ultimately, I think this is the way any usability-oriented proposal
needs to be evaluated: step back and look at it in the context of the
various types of people Django aims to please, and their priority
relative to one another. This will tell us immediately if it's a clear
win or a clear loss, and let us better choose the issues that are
worthy of extended debate.
Thoughts?
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Kenneth Gonsalves
On 01-Jun-06, at 12:32 PM, James Bennett wrote:
>
> This would, probably, offer some benefit to novice developers, because
> it's a couple less things they have to do at the outset (though it
> arguably adds in some "magic" that it's better to have them
> understand). But it offers zero benefit to experienced developers and,
> most likely, would hinder them: they're going to want to develop on
> something resembling their production environment, which means
> probably MySQL or PostgreSQL (maybe even Oracle once the adapter for
> it stabilizes sufficiently), and there's no guarantee that they'll
> want to use the admin app -- there are plenty of uses for Django that
> don't involve the admin at all. So this gets in their way and detracts
> from the out-of-the-box usability of Django for its core audience.
and as far as postgresql is concerned, i see a lot of use of
triggers, rules, procedures etc which would be put in the db
independantly of django. I also am already seeing bulk data entry,
either script based or otherwise pulled from other sources, also
directly to the database outside of django - so i agree, catering to
group one should be the priority
>
> Thus, this proposal should probably be rejected.
as far as trunk goes - no harm having it somewhere in contrib if it
passes muster. But not a priority
--
regards
kg
http://lawgon.livejournal.com
http://avsap.org.in
Adrian Holovaty
> It's a simple truth that you can't please all of the people all of the
> time, so at some point in any development process you have to sit down
> and mark out three groups:
James, you really hit it on the head here. My personal belief is that
Django is first and foremost a programmer's tool, and I am more
interested in optimizing it for experienced Web developers than for
people who have never written a computer program. It would be
fantastic if Django *were* easy enough to use that non-programmers
could use it, but we shouldn't go out of our way to introduce
high-level beginner-friendly features at the expense of confusing and
frustrating experienced developers. It's a fine line. You're right to
note that we should keep that fundamental focus.
I hope this doesn't get interpreted as a slight against
non-developers. Ideally developers and non-developers alike would find
Django to be a useful tool -- and, actually, that's already happening.
But as we develop the framework further, we shouldn't introduce
functionality that appeals to the novices at the expense of
frustrating the experienced developers.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Kenneth Gonsalves
On 01-Jun-06, at 8:53 PM, Adrian Holovaty wrote:
> I hope this doesn't get interpreted as a slight against
> non-developers. Ideally developers and non-developers alike would find
> Django to be a useful tool -- and, actually, that's already happening.
like wilson's little howto - but he *did* have top django programmers
to do what he wanted in the background
Ilias Lazaridis
*COMPACT*
So, why not create an option for "startproject", to keep everyone (you,
me, the unexperienced, the experienced) happy? Flexibility and freedom
of choice is a nice thing:
$ django-admin.py startproject eval quick-start
$ django-admin.py startproject eval # uses standard-project
This would allow to simplify the quick-start:
http://case.lazaridis.com/multi/wiki/DjangoProductEvaluation
And this would additionally allow users to setup own project-templates.
-
*THOROUGH*
I don't understand why you (all) exaggregate so much with your writings
(e.g. "for people who have never written a computer program").
Even if Django targets the highest capable developers (or especially
then), simplicity and automations should be provided:
http://lazaridis.com/core/product/case.html
-
Reading your comments, i am wondering if you should possibly correct the
home page of django:
"Django is a high-level Python Web framework that encourages rapid
development and clean, pragmatic design."
"It lets you build high-performing, elegant Web applications quickly."
"Django focuses on automating as much as possible and adhering to the
DRY principle."
"Define your data models entirely in Python. You get a rich, dynamic
database-access API for free — but you can still write SQL if needed."
-
Those writings (high-level, quickly, automating, no-SQL) create several
expectations to a visitor. Expectations which django currently does not
fulfill (at least in the context of a quick-start). This leads to a
unnecessary negative User Experience.
I don't understand why the team ignores the importancy of a simple
quick-start and a positive user-experience (avoid unfulfilled
expectation), which is essential to get new users on board.
And the steps to achieve this are minimal and will in no way "frustrate
experienced developers" (if implemented right).
-
Notes:
this thread referes to:
http://groups.google.com/group/django-developers/msg/063681c3abb92441
.
Wilson Miner
> Those writings (high-level, quickly, automating, no-SQL) create several
> expectations to a visitor. Expectations which django currently does not
> fulfill (at least in the context of a quick-start). This leads to a
> unnecessary negative User Experience.
This line of reasoning is very strange to me. We've established a
hypothetical visitor who is having a negative User Experience. Who is
this user? I'd love to talk to him (or her) and get a concrete idea of
exactly what expectations he had and how his experience with Django
didn't match up. Then we can have a productive discussion about how to
solve a real problem, instead of going back and forth about a
hypothetical situation which can never be practically solved.
James Bennett
> me, the unexperienced, the experienced) happy? Flexibility and freedom
> of choice is a nice thing:
OK, now I have to start questioning credibility. "Accomodate novice
and expert users by switching between 'basic' and 'advanced' versions
of the tool" is one of the most fundamental usability mistakes out
there.
> Even if Django targets the highest capable developers (or especially
> then), simplicity and automations should be provided:
Automation is provided where automation is useful for the core target
audience, or where it doesn't negatively impact that audience. We
automate database-table creation, for example.
Funny that someone who claims we're exaggerating would write in a way
that makes it sound like Django provides no automation or simplicity
at all.
> Those writings (high-level, quickly, automating, no-SQL) create several
> expectations to a visitor. Expectations which django currently does not
> fulfill (at least in the context of a quick-start). This leads to a
> unnecessary negative User Experience.
How so? I've written dynamic web applications from scratch before, as
have the people Django will primarily be useful to; compared to that
process, development with Django is unbelievably fast; projects which
used to take weeks or months now take days and sometimes only hours.
And all of that text seems, to me, to be targeted at -- and I know
this is a crazy thing for a web development framework -- developers.
Django lives up to the claims it makes. It does not live up to
contrived situations like the ones you keep throwing out -- perhaps
you should dig up a good book or two on user profiling for usable
design.
> I don't understand why the team ignores the importancy of a simple
> quick-start and a positive user-experience (avoid unfulfilled
> expectation), which is essential to get new users on board.
The first time I ever tried Django, about a year ago now, I walked
through the tutorial. In about half an hour, I had a functional web
application with an attractive administration interface.
Don't tell me that isn't a "simple quick-start and a positive user
experience". If your definitions of those terms just involve typing a
command and seeing lots of things scroll by on the screen (which
doesn't seem all that unlikely, given some of your suggestions),
perhaps you should begin"auditing" Rails instead.
Luke Plant
Ilias Lazaridis wrote:
> So, why not create an option for "startproject", to keep everyone (you,
> me, the unexperienced, the experienced) happy? Flexibility and freedom
> of choice is a nice thing:
>
> $ django-admin.py startproject eval quick-start
>
> $ django-admin.py startproject eval # uses standard-project
The 'standard project' would presumably include these things:
- User, Group, ContentType etc models
- admin app, completely set up with URLs etc.
Once they have created this, they will have a nice administration
interface for administering...*nothing*.
That is because the 'standard project' does not contain any models that
are actually the basis of any web app (apart from the unlikely
situation where the Users and Groups are the only thing you want to
display on your web site). Django is not an out-of-the box solution.
So, what situation is the user (i.e. the developer) in now?
- They will *still* have to learn the django-admin commands for
creating apps, installing models etc -- they have just wasted time
learning some magic commands they will never need again.
- They are also not likely to understand that the admin they have just
installed is really 'optional'
- They will probably not appreciate how powerful the admin actually is
(i.e. that it can be used for *any* model, not just the provided ones)
- They haven't yet *begun* to explore the API for creating and using
models (probably the most important part of their evaluation, since
they are *developers* and will spend most of their time working with
models and views).
I think this proposal would actually decrease the 'user experience'.
The 'wow' factor of the admin, IMO, comes almost entirely from the fact
that it works with the *developer's* models. (It's very pretty and
nice, but if all it did was the built-in models it would just be Yet
Another Admin Interface). For developers trying either to evaluate or
just get going, early exposure to writing their own code (especially
the models) is crucial, and how well the framework and admin works with
their own models is what they need to know. I also think the fact that
the tutorials gets you using a Python shell nice and earlier is
brilliant.
(I guess people coming from a PHP background won't appreciate some of
these things, such as the Python shell etc -- I've seen some writeups
which kind of assume PHP developers are going to use Django without
actually learning Python. Maybe we need a 'Django for PHPers' that
basically says 'You should be able to make it through the tutorials,
but you need to learn Python before using Django in earnest'. There
are some great Python tutorials that get people going very quickly, but
trying to do it *more* quickly than that would be pointless).
Luke