[Nix-dev] UI management (Was: Use Haskell for Shell Scripting)

[Ertugrul Söylemez]

>> It's not that esoteric.  Think about the average 2013 laptop or PC
>> with plenty of RAM.  When you're done with a certain task, you close
>> its window, simply because you're used to that and perhaps because
>> you draw a relationship to the physical world, where you prefer your
>> desk to be clean and organised.
>
> Erm, some of the things need to know they should stop eating CPU
> cycles and stop touching their esident working set — I do think that
> my 8 GiBs of RAM are sometimes better used with more disk caching of
> my active-in- brain tasks and not caching LibreOffice and
> Firefox. Sometimes not.

That's actually fairly easy to handle on Linux by using namespaces,
sigstopping and sigconting.  There is probably also a way to force
programs to go to swap by using cgroups.  Be patient, I'm still working
on a DSL for this design. =)

Unfortunately it entails removing systemd from the top of the process
tree, which is a lot of work for a single person, but I'm highly
motivated.  By the way, this is not my usual systemd hatred.  There are
technical reasons to remove it from the top.


>> So what's the solution?  Simple: Workspaces must be cheap, dynamic
>> and extremely easy to manage.  There should not be a rigid mapping
>> between workspaces and windows.  Windows should easily be able to
>> belong to multiple workspaces.  A generalised xmonad could do it, but
>> the current one can't.
>
> My experience says that moving towards your goal is a good idea w.r.t.
> status quo, but halfway there you'll switch the direction.

I'm not sure why.  This is not about a certain UX concept, but just
about a window manager being sufficiently general that I could start to
experiment.


> What is your vision and what is your experience on your way there?

Wow, big question!  I'll try: It's twofold.

A long time ago (≥ 13 years), little me was using Windows, and he always
thought that there is something wrong with this concept of "windows on a
desktop".  "Folders" felt unnatural, too.  Everything about my operating
system tried to mimic the physical world.  I never really cared about
learning curves, so I always asked myself what it would look like if we
could use the potential of a virtual space to its full potential instead
of locking ourselves up within the boundary of our own imagination
("office work" means "sitting in front of a desk" to most people).

A later me had already switched to Linux and discovered workspaces.  It
was a minor improvement, because this time you have multiple virtual
desks, so you had no reason to drop something on the floor (minimising).
But it still felt wrong, and this feeling continues to this day.

My vision for UX is that we move away from the physical world.  In the
computer we can construct our own universe with the rules of physics
constructed or bent to support the work we are doing, perhaps in a fun
way.  Let's not think of the space on our screen as a virtual desk.
It's a projection of a space that we programmers create, and we have
complete freedom to create whatever we want!  In the same way I always
thought that our filesystem concept is wrong.  There is no inherent
reason to have "files in folders".  I believe that a disk should act
more like a giant mutable variable.

My vision for software in general is what I call "organic software".
I'm actually writing an article about it, so let me just quote a few
paragraphs of the section *Moronware* from that one:

"View programs, especially interactive ones, as part of your team.
Imagine that you have handwritten a bunch of documents that you would
like me, your teammate, to review.  So you hand me a copy and I start
reading.  Later that day you return to my office, and I'm just sitting
there, doing nothing.  You ask what's wrong, and I point to one of the
words in the document I were reading.  I simply couldn't decipher your
handwriting, so I stopped and waited for your assistance instead of
making a note and continuing.  Seems absurd, right?  No good teammate
would do that.  That's true.  Our programs are probably not such good
teammates.

When humans act the way our programs do we like to call them morons.  We
should do that with programs instead of humans.  They aren't self-aware
beings (yet), so they won't be offended, and they really do act like
morons.  I propose the term *moronware*.

How can we write software that isn't moronware?  Good design and proper
responses to exceptional circumstances can make our programs faster,
more responsive, more flexible and less like untrained animals.  They
make our programs *dependable* and in the end *trustworthy*, because we
can feed tasks to our program and focus on other things or even just
pick up a cup of coffee, because we *know* that it will do its best to
complete as much as possible without our intervention."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150210/e7453499/attachment.bin