Re: [9fans] UI design | enhancements.

[Marshall Conover <marzhall.o@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3611 bytes --]

Hi Darren!

I can see how 9's current UI could be considered a 'roadblock' to the
average user due to its unfamiliarity, and making it closer to modern looks
may make plan 9 pass the smell test for users more often. Personally,
though, it seems like a bit of a slog; there's not much exciting going on
in changing a UI to look like 'every other' UI, and I'd also wonder about
maintenance - you might update it to look familiar now, but in three years
where will it be, especially with web frameworks changing things so
frequently and invading the desktop with elektron? That said, if it does
draw more users, upkeep might get easier (just having people prompting with
issue reports can be productive), and it's genuinely nice to have a more
active community.

But, I'd be really interested to see it taken a step further. Instead of
just a facelift, I'd love to see changes that show a reflection on modern
UIs and their problems, and attempts to fix them. That'd not just remove a
roadblock for new users, but create change that may actually draw them.

For example, I feel super squished on a single screen, but I've come to
dislike the awkwardness of switching between multiple 'workspaces' or
working with tiling wms. So I'm playing around with rio at the moment to
see if adding a 'panning' effect, where you treat the desktop as an
infinitely-scrollable table and allow the user to 'pan' around the table,
could be a natural approach to feeling less squished. It may end up being
even more awkward and painful, but it may also end up being something I'm
left wanting for in modern DEs - that could be an attraction to 9.

In something that I feel relates closer to the heart of 9, one problem I
see in modern UIs is the inability to easily interact between programs.
Each UI acts as an island, and the best generic interface for interaction
you can get between them is allowing programs to send screen clicks, with
the nightmare quickly following of figuring out how to know where to click.
Web APIs are somewhat en route to addressing that with their REST endpoints
and swagger API definitions, but it seems so much more simple to instead
use files and directories over 9p.

Getting really out there, I'd love to see a tightly coupled way of
representing the commands you can send to a program via its ctl file API in
9 and a visual representation of that program in rio. I'd love if the UIs I
was using in a program corresponded to their filesystem API so much as to
be almost a mapping, perhaps even letting you generate a UI from the
filesystem API and some simple mark(down|up). I think a shell that worked
off of this concept could be fascinating - not unlike a browser in some
ways, but in keeping close to the filesystem abstraction, perhaps allowing
for much better interaction with the small, text-stream focused programs
that the unix mentality prefers.

In sum, I'd be happy to see an increase in users from a facelift, but what
I'd love to see are new draws that fix modern problems.

On a more practical level, you may find it notable that the nuklear lib
<https://bitbucket.org/mischief/libnuklear> has been ported for plan 9. It
may be a good start to create a UI that users coming from current workflows
will be comfortable looking at and interacting with. If you want to chat
with the porter of the nuklear lib for 9, you'll find him in this plan
9-focused discord server: https://discord.gg/6daut5T. You may also find
it's a good place for discussion like this.

Thanks for starting the discussion, and good luck!

Marshall

[-- Attachment #2: Type: text/html, Size: 4014 bytes --]