Opened 7 years ago

Last modified 4 months ago

#738 assigned enhancement

Router console redesign

Reported by: guest Owned by: sadie
Priority: minor Milestone: 0.9.39
Component: apps/console Version: 0.9.2
Keywords: console design usability representation Cc: zab@…, fnord@…, alex_the_designer, alex_wykoff
Parent Tickets: #2330

Description

okay guys.. lets face it, the defualt console is an ugly hodgepodge of links, settings pages, info pages, and plugins. the -fux branch by dr|z3d is a step in the right direction, but ultimately is little different to the default. the console is inconsistent and very confusing, even to an experienced user. i don't mean the content, just the organisation. as i understad it str4d is working to seperate the router code from the console code, but a fundamental redesign of the console pages is badly needed.

Subtickets (add)

#1054: Better UX - explain options betterenhancementassignedsadie
#1766: Tag missing i2ptunnel stringsdefectopen
#1140: There should be tooltips for tunnel statusdefectassignedsadie
#1766: Tag missing i2ptunnel stringsdefectopen
#2392: i2p console design - migrate pngs to svgs and replace as many as possible with icons from featherenhancementassignedsadie

Change History (32)

comment:1 Changed 7 years ago by echelon

  • Component changed from router/general to apps/console
  • Milestone changed from 0.9.3 to 0.9.4
  • Priority changed from major to minor
  • Type changed from defect to enhancement

The basic startup router console is cleaned up and has only very basic info on it.

comment:2 Changed 7 years ago by zab

  • Cc zab@… added
  • Priority changed from minor to major

I agree completely with the complaint raised by the original ticket, and disagree with it being a minor problem. It is a major problem and a major obstacle to i2p adoption.

comment:3 Changed 7 years ago by killyourtv

  • Cc killyourtv@… added

It indeed could use work to make it more 'inviting' to the more n00bish users, e.g. /console has a lot of good info on it but the wall of text is intimidating. Not to belittle what's been done in Fux-land, none of those changes--thus far--have made the console "less scary".

IMO, the most important things users need to know are
1) how to configure the browser
2) how to hop on IRC.
3) how to set up their very own site

...and that information won't be easily spotted with a great wall of text.

So...since I'm not "a designer" I'll work on trying to improve the text at /console. The information will still be available but it can probably be tucked away elsewhere, initially out of view, so that the first (or second) thing a user sees isn't a long (and potentially intimidating for new users) text. Reading Is Hard™ so the reading should be kept to what needs to be read (with longer texts available to those that <gasp> don't mind reading).

comment:4 Changed 7 years ago by zab

KYTV makes some excellent points. To that I would add that if you have access to a real-world grandma or an elderly person that is willing to give you some of their time you can gain extremely valuable insights. Observe their behavior when faced with the UI and take note of what the so-called "pain points" are.

I'm very excited this issue is being looked into as it is a critical step in the right direction.

comment:5 Changed 7 years ago by zzz

I'd like to hear the OP's suggestions for improvement.

comment:6 Changed 7 years ago by guest

zzz, i am the end user. i complain, you fix. as the leader of the project you should have your own suggestions, not rely on some anon to give them to you. i have stated and explained a problem i have, you improve upon it. that is how open source works.

comment:7 Changed 7 years ago by zzz

@OP you're taking an extremely narrow view of the "end user" role and how "open source works". Your "complaints" are devoid of specifics. Since the issue is an aesthetic one, I'm not at all out of line to ask for suggestions. If you don't have any, fine, but don't somehow make me the bad guy for asking.

comment:8 follow-ups: Changed 7 years ago by guest

  • Keywords usability grandma added

I think what @OP is doing is showing us how 99% end users out there really think. I'm not the OP but I wouldn't be surprised if he / she is a developer for one of the BitTorrent clients. We observed the exact same mentality among LimeWire users

--zab

comment:9 in reply to: ↑ 8 ; follow-up: Changed 7 years ago by guest

Replying to guest:

I think what @OP is doing is showing us how 99% end users out there really think. I'm not the OP but I wouldn't be surprised if he / she is a developer for one of the BitTorrent clients. We observed the exact same mentality among LimeWire users

--zab

looks legit

comment:10 in reply to: ↑ 8 Changed 7 years ago by zab

Replying to guest:

I think what @OP is doing is showing us how 99% end users out there really think. I'm not the OP but I wouldn't be surprised if he / she is a developer for one of the BitTorrent clients. We observed the exact same mentality among LimeWire users

--zab

That's me, I'm traveling and don't always dare log in using the hotel wi-fi. I'll be confirming comments whenever I can. Sorry about this, will try to keep it to a minimum.

comment:11 in reply to: ↑ 9 Changed 7 years ago by zab

looks legit

legit as in
a) it being a comment from me or
b) the observation that 99% of users are complete !@$#% being legit? ;-)

comment:12 Changed 7 years ago by zzz

  • Milestone 0.9.4 deleted
  • Summary changed from I2P router console to Router console redesign

@zab you're taking an extremely charitable reading of comment 6, which on plain reading is that it's all my problem and that nobody else has anything to contribute except complaints. That's ridiculous. There's nothing in this entire ticket that either helps or motivates me to work on this at all. Quite the opposite, as it proves that the console issue is a minefield of trolls and haters. If this ticket somehow is motivational to somebody, I'm astounded. Comment 6 exemplifies everything that is wrong with this project. I'm happy that you're "very excited" (comment 4) but don't hold your breath.

comment:13 Changed 7 years ago by zab

"Always Look On The Bright Side Of Life(TM)". ;-)

I'll agree the OP is behaving like a troll and a hater but comment 6 is still very useful exactly because it "exemplifies everything that is wrong with this project". It helps us transform an unknown unknown into a known unknown and helps us to know what we're dealing with. It's sad but if we expect every user out there to be a constructive contributor the disappointment will be even worse.

comment:14 Changed 6 years ago by fnord

  • Cc fnord@… added
  • Keywords console design representation added; grandma removed

I've noticed the simplified console which is pretty cool imho. So compliments for that.

The console is a local thing - it runs on your own system and you connect to that. It is designed to give you a good amount of info about what is happening and is comparable to what you see under the hood of a car. Everyone knows how to open the hood -- not everyone knows what they are looking at once it's opened.

I strongly feel that we should not modify the console to something it wasn't designed to be. For example, you can start up i2p without an internet connection and open the console page in your browser. But because there's no internet connection, you didn't "open i2p" in your browser. You opened a local console.

So my point is -- I'd rather leave the console as it currently is (purpose: backend), and make a new page (frontend) for i2p that is actually served over the i2p net. For example http://start.i2p/ or http://home.i2p/ aka the landing page. Doing it like this will prevent us from having to rebuild console pages for sheer convenience and the landing page can be a convenient and appealing starting point for the (new) i2p user.

One more thing -- IMO we shouldn't focus on making i2p understandable for *everyone* because we'll never reach that goal. Instead I'd argue that we're already on a good path. Difficult non-i2p tools that come to mind are sabnzbd, sickbeard, couch potato. These are very difficult to learn. But the incentive of those programs is to download films and TV shows and those are the reward people get after learning how the tools work. But I'd argue that these tools are far more difficult to learn than i2p.

tl;dr: make the console less important and make a cool landing page that is served over actually i2p.

What do you guys think?

comment:15 Changed 6 years ago by fnord

correction: tl;dr: make the console less important and make a cool landing page that is actually being served over i2p.

comment:16 Changed 5 years ago by zzz

  • Priority changed from major to minor

comment:17 Changed 4 years ago by str4d

Some discussion in #i2p-dev prompted me to resume my "on-again-off-again" thinking about this ticket. I have identified what I believe are the key questions that an average user of I2P might ask about the routerconsole:

  1. Can I access anything (yet)?
  2. What can I access?
  3. How can I access what I want to?
  4. Why can't I access what I want to?
  5. What/where are the bundled apps?
  6. How do I install/uninstall apps?

Anything that is not relevant one of those questions is IMHO not important to the average user. Now, let's allocate the parts of the current routerconsole to those questions:

  1. Start/stop controls, network(/firewall) status, tunnel status
  2. Address book, "Sites of interest"
  3. Hidden services manager, help page (to explain the HTTP proxy)
  4. Error pages, logs
  5. "I2P Services" in sidebar (duplicated amongst the entries under "Local Services" on /home)
  6. Part of the top of configclients (bundled webserver), the middle of /configclients (bundled apps), the bottom of /configclients (plugins).

The remainder of the routerconsole serves no purpose to the average user for achieving their goal (which I define as answering their question). Leaving them visible in the UI is therefore needlessly complicating the user's decision tree.

My suggestion is that the routerconsole redesign focus on the areas associated with these six questions, both to improve them individually and to rework the information architecture of the routerconsole to place them at the forefront. The rest of the features should be hidden until the user asks for them (perhaps via routerconsole.advanced=true, or a new option that can safely be enabled in the UI without providing XSS vectors).

comment:18 Changed 4 years ago by rhoze

I've begun working on a startup wizard/mini-tutorial for new installs that may help with some of this stuff. Not directly or immediately related to this bug, but I figured it would be good to throw the link here: #1473

comment:19 Changed 4 years ago by rhoze

One thing that I thought of is that the big apps would probably benefit from more prominent placement - specifically I2PSnark, Susimail and the webserver (as linked by "Email Torrents Website" on the expanded infobar). I think these should get actual buttons (perhaps akin to the "Restart" and "Shutdown" buttons already there), maybe with icons, and they should be visible even in the "simplified" form of the infobar. As they are right now, they are lost in a sea of other small text links and I don't think many people have much reason to find them.

It's very good that they are given big, juicy buttons at the bottom of the Console Home page, but even just being at the very bottom, there, means that a lot of people won't pay them much mind - especially among so many other icons down there. I think these three apps specifically should feature at the top of the interface, probably in the infobar (like where their text links are currently), and be nice and invitingly clickable. There may not be space for three icon buttons to sit horizontally on one line, there, so it will probably take some experimentation and mockups to see how this could look.

comment:20 Changed 4 years ago by str4d

Yes, this is what I was referring to with question 5 above. The bundled apps are something users care about, but they are not easy to identify in the routerconsole, being mixed in with other utilities that they don't care about. Making them more prominent (with actual buttons, or a clear section, or...) would improve this.

comment:21 follow-up: Changed 4 years ago by zzz

If we want apps to be more prominent we can play with the styling and/or placement - but I think there's a big difference between 'apps' and 'buttons'. Buttons are for controls. Not for launching things. Look at any smartphone and the two look a lot different. Apps should definitely not have the same style as restart/shutdown.

It's possible that some minor styling on /home will be all that's necessary.

I'm unconvinced that the apps at the bottom of /home are so easy to overlook. (comment 19). There's only 9 items there, and 3 or 4 are apps, depending what you count.

Agreed that 'apps and configuration' is a bad combination, we should probably split them in two. But that will push things down farther, unless we put apps and configuration sections side-by-side instead of one over the other. Also beware, the CSS for /home is fragile.

'router console redesign' is such a big canvas. Let's continue to tweak /home first, followed by updating /console in the same spirit.

comment:22 in reply to: ↑ 21 Changed 4 years ago by str4d

Replying to zzz:

If we want apps to be more prominent we can play with the styling and/or placement - but I think there's a big difference between 'apps' and 'buttons'. Buttons are for controls. Not for launching things. Look at any smartphone and the two look a lot different. Apps should definitely not have the same style as restart/shutdown.

Agreed, and I believe that is what rhoze means too.

It's possible that some minor styling on /home will be all that's necessary.

I'm unconvinced that the apps at the bottom of /home are so easy to overlook. (comment 19). There's only 9 items there, and 3 or 4 are apps, depending what you count.

Agreed that 'apps and configuration' is a bad combination, we should probably split them in two. But that will push things down farther, unless we put apps and configuration sections side-by-side instead of one over the other.

Side-by-side would be fine with me. In fact, I was imagining replacing the "app buttons" with a list, with the icon on left of each list item, title on right and description under it. I particularly think that the description needs to be shown for the apps; several people I have talked to in person (who had no previous routerconsole exposure) said that the tooltips were very non-obvious, and the only "app/eepsite buttons" that made sense were the ones with the well-chosen icons.

Also beware, the CSS for /home is fragile.

If it is fragile, IMHO it deserves to be made more robust :-)

'router console redesign' is such a big canvas. Let's continue to tweak /home first, followed by updating /console in the same spirit.

As I think I have said earlier (not checking scrollback), I think most of the content on /console deserves to go into /help.

Personally, I am going to focus my routerconsole design energy into a new /configapps page, which will contain a subset of /configclients geared heavily towards the user, rather than just replicating the config files in the UI. I want to use it as a testing ground for both a user-centric information architecture, and a new design. Being a new page, it can be played with as much as we want (using separate CSS etc.) without affecting any of the existing routerconsole pages; then if we get to a design/UX that we are happy with, we can discuss potentially migrating and/or redesigning other pages.

comment:23 Changed 4 years ago by zzz

I still like the cellphone paradigm of /home but let's see what you come up with.

re: /configapps, ack, as /configclients is indeed a mess.

re: /console, it is of course the same disaster it's always been, papered over by /home.

comment:24 Changed 4 years ago by user

This coment os more about /i2ptunnelmgr and /configkeyring.
On irc elll aka admin2501 @ mempo.org had some problems with setting up encrypted leaseset,
and found it all

elll: this all is confusing as fuck
psi: there's a field call "local destination" in the details page with the full destination blob
elll: psi: is that it? because I thought other developer said to not use it, maybe I read it wrong? <str4d> elll: the "local address" (ie. the address of the service on your computer that the server tunnel is pointing to) is never published
elll: so is "local address" the full address of the destination, the public key of my server address? that also is called b64?
user: but now that you have the long one, use the long one. it's not doing any harm
elll: is b64 other name for "local destination"?  should I give local destination to clients that should connect to my hidden (encrypted leaseset) server?
user: yes, the "local destination" on the tunnel details page is that is the b64
elll: why not call it "b64"
user: the b32 is the shorter one you see on the previous page where all your local tunnels are
user: hehe, yes you are right. 
elll: that page needs a "Help" button with exact description what each setting is/does and shoult it be kept private or published or what 
user: yes
elll: so... "local destination" is then: i2p-address of your server, in the b64 format
user: so what do you propose?
user: should things that are "save to share" be marked differently?
user: yes
elll: [private-key] (red color) - this information must be kept SECRET, if someone would stole it he could do bad things (compromise your privacy or security etc)
elll: [private-key] (red color) - this information must be kept SECRET, if someone would stole it he could do bad things (compromise your privacy or security etc). Do BACKUP of this information or you will probably lose ownership of this resource (e.g. of this server as known by given public address).
elll: [private-password] (violet/red) - this information acts like a password to access given resource (e.g. to access this server). You should give it to users who you want to allow access here.
user: it's much text. that would have to be down below on the page or a separate help page
elll: [public-key] (green color) - this information acts like your name. You probably want to publish it. People must know it to access this resource (e.g. to access your server, e.g. view your web page).
elll: user: no this is just the legend, it can be at bottom.  
elll: And then use this tags/colors in the form
elll: [local-info] (blue) - this is information written just here (e.g. in your i2p node configuration) it is not shared with other people and can not leak to them.
elll: and then instead "Local destination(L): "  do   "Address of server [public-key] in b64 format:"

and

 elll: does the keyring config lack delete-key button?
 elll: oh nevermind I'm blind
 elll: though, yeah - you must remember the correct destination to delete it (it's not shown in the table). the delete button should be added to each entry of the table with existing keyrings

comment:25 Changed 3 years ago by zzz

Add a subticket #1054.

comment:26 Changed 3 years ago by zzz

  • Owner set to str4d
  • Status changed from new to assigned

comment:27 Changed 3 years ago by zzz

Add a subticket #1140.

comment:28 Changed 12 months ago by zzz

  • Owner changed from str4d to sadie

comment:29 Changed 8 months ago by zzz

  • Milestone set to 0.9.38
  • Parent Tickets set to 2330

comment:30 Changed 6 months ago by sadie

Improvements to the router console will be ongoing post .38
For now, we hope to visually declutter with more simple icons and a new background.
'
The patterning/ sorting of documentation needs to be considered from a use - case scenario, ie, first time/ casual user docs, content creation docs, technical docs.
Some of this guidance is going to come from how we restructure our documentation on the website. From there we can use this pattern on the console to stay consistent from a usability perspective.

The first step may be to get all post installation documentation sorted for our first install flow.

comment:31 Changed 5 months ago by zzz

  • Cc alex_the_designer alex_wykoff added; killyourtv@… removed
  • Milestone changed from 0.9.38 to 0.9.39

New light background in f22bef732277cd529daaefe2d0310e1df5b1b391 0.9.37-12
Remainder pushed to .39 as decided at meeting on 2018-12-29.

comment:32 Changed 4 months ago by alex_wykoff

Add a subticket #2392.

Note: See TracTickets for help on using tickets.