Le vendredi 22 mai 2009 23:38:35, Matthew Toseland a ?crit :
> On Friday 22 May 2009 17:31:46 Cl?ment wrote:
> > Hi all,
> >
> > First, let's see the current situation :
> >
> >
> > #Navigation :
> >
> > 9 items is really the max we can afford. Currently there are 9 items, but
> > they aren't all necessary, and can confuse the newbies.
>
> Agreed, we need sub-menus.
>
> > #Browse Freenet page :
> >
> > The ?Search Freenet? field and bookmarks are definitly a good thing.
> > However, why do we have :
> > ?Fetch a key? : we don't want to fetch a key, we want to browse Freenet.
>
> Some users DO want to fetch a key. But maybe it should be on the queue
> page.
>
Yep, here I just list the points that I don't find logical. If we want to fetch
a key, we go in the downloads page. If we want to visit a site, we need a box
to do so (see below, I forgot to put that on the browse page proposition)
> > ?Version Information & Node Control? : we don't care, we just want to
> > browse Freenet.
>
> When they come to us, we usually need to know the version number.
Sure, but I don't think it's the right place to put this information. It
should be under the status/statistics page, or maybe we can add a submenu
status/node info.
>
> > ?Current Activity? : idem
>
> Fair point.
>
> > #Messages :
> >
> > I agree we need to inform user when something is wrong. However, for the
> > bookmarks, it's not the good place.
> > I don't think either that there should be one page just for the messages
> > : sometimes there is no message, it just wastes space.
>
> In which case we don't show the menu item.
>
Ah, my bad then. But it's not really better, since menu item shouldn't
disappear : we need consistency over the time. One thing has exactly one
place, and always the same.
> If we put all the messages on the main page in full, they take up so much
> space that newbies don't see the rest of the page.
>
Yep, that's not a solution.
> There are a number of messages that take up multiple slots on the message
> list when they should really just post a summary and point to another page
> where they are in full (e.g. n2ntms should be on the friends page, bookmark
> updates on the browse freenet page).
>
> We should probably either
> 1) not link the messages page from the main menu, but keep it, or
> 2) make messages expand themselves when you click on them
>
> > #Download and Upload :
> >
> > No clear separation between dowloads and uploads.
>
> Agreed. WHEN we have sub-menus, we should separate the two.
>
Sub-menu should be easy to implement.
> > #Plugins :
> >
> > This is a mess : here we access the plugins, we can add an official
> > plugin, we can add a plugin from an url, we can add a plugin from
> > freenet.
>
> It is not very user-friendly, because the box doesn't tell a newbie very
> much, and the dropdown for official plugins doesn't give any indication
> what they do. However, the functionality is important. We may want to split
> this into multiple pages under a sub-menu, but we certainly want to
> document the official plugins.
>
Yep, see the Configuration/Plugin page.
> > #Connections to friends + connections to strangers :
> >
> > Why 2 separate pages ?
>
> Because they are different! Friends and Strangers are completely different
> IMHO. Friends have names, you can send them text messages, etc. Strangers
> are just numbers - normal users don't care about their IP address, etc.
>
Hmm, ok.
> > Why showing informations about the current activity of
> > the node ?
>
> Good question. Some of it is per-node so clearly has to be here (but only
> in advanced mode), but the status at the top is debatable.
>
It's redondant information yes (I mean the status).
> > All is mixed : managing nodes (adding/deleting) and showing their status.
> > Why are the ports showed ?
>
> Where do you propose we put them? On the Internet Connection page, I guess?
> Some users will need to know them for port forwarding reasons.
>
Maybe on the Status/node info page then. (I forgot that point in my proposal)
> > #Statistics :
> >
> > Nothing to say. It's just statistics. Maybe divide in several category.
>
> It's huge yeah, it should probably be split eventually.
>
> > #Internet Connection :
> >
> > ??? It doesn't even work here... And when it works, it shows debug
> > informations or really advanced ones. Why a level 1 page for that ? (why
> > a page for that in fact..)
>
> In "Simple interface", my node shows:
>
> Connectivity
> UDP Darknet port 24374 Port forwarded
> UDP Opennet port 37024 Maybe port forwarded
>
> This is not immediately comprehensible by a new user. We will tell the user
> that they need to forward specific ports with a useralert if we need to.
> However, this information may be of use somewhere, it should probably be
> hidden away though.
>
I'm not saying that these informations aren't usefull. They're just not in the
right place (imo).
> > #Configuration :
> >
> > A big big mess. Really. When in simple mode, it's almost ok, but in
> > advanced mode....
>
> Please could you elaborate on that a bit?
>
Well, one unique page for all the configuration item is not really usable. I
often take 10-30 seconds to find something on the configuration page (advanced
mode)
> > Why a link to the security levels just on side of mode switching buttons
> > ? It's not even related.
>
> Security levels are part of configuration!
>
Yes, they are part of configuration. They're simply not like simple mode or
advanced mode. (sorry if I wasn't clear enough :s)
> > #Mode switching :
> >
> > It's a pita : I have to go in the advanced configuration page to change
> > this, or to click on the button on each page
>
> I don't see any alternative given that most users will only want to see the
> simple stuff, but devs and some power users will definitely want to see
> more.
>
What I propose is to make the switch global and always displayed (in top right
corner or something like that).
> > Now, what do I propose :
> >
> > #Navigation :
> >
> > ##Menu :
> >
> > (level 1, category : noun; level 2, action : verb)
>
> Okay, first point is you use sub-menus. I strongly approve of sub-menus.
> Caco_Patane was working on them, but if he doesn't get back to us somebody
> else will have to do it. Really it's not a huge change, it just needs
> rewriting the CSSes and some tiny changes in the java code after that.
>
We can expect that to be done relatively soon I think. Without sub-menu, we
can't make a decent ui.
> > Freesites :
> > => Browse Freenet
> > => Insert your own site (when available)
>
> Agreed.
>
> > Filesharing :
> > => Download files
> > => Upload files
>
> Agreed.
>
> > Discussion :
> > => Talk with FreeTalk (when Freetalk available)
>
> We were thinking of calling it "Message boards" or "Forums" or something,
> but yes it needs to be a top-level item, because it has its own menu.
I let you choose the wording, english is not my natural language ;)
> > Status :
> > => Show the {number of messages} messages (if there are some)
>
> Putting the messages *only* here is a bad idea. Some of these messages are
> IMPORTANT. What we need to do is: - show the summary on the Browse Freenet
> page and maybe others
> - reduce the number of messages by coalescing them and shifting them to the
> relevant pages: "You have 6 messages" with a link to the Friends page
> rather than one for each n2ntm, similar with bookmark updates.
>
> I agree that having the Messages page under Status makes sense however.
>
Ok, then maybe we should consider having a status bar (like in my first
mockup). I don't really have idea for that though, so if anyone has one...
> > => Show connections
>
> No, not as a single item. Connections to Friends are something that should
> be treated separately from connections to Strangers. You can chat with
> Friends, send them files, view their bookmarks, you know their names, you
> care about them to some degree and trust them to some degree (which may be
> explicitly configurable for each). Connections to strangers are different -
> unless you are a geek or your node is behaving very oddly you probably
> don't care about them.
>
> IMHO Friends should be a top level item, or at least a separate item under
> Status.
>
Ok for separating them under the status menu. Once we got more features for
the friends page, we can move it on top (right now I don't find it very usefull
to have it on top, and it may be confusing to have the two connection page so
separated).
> > => Show statistics
>
> I agree the stats page should be on a sub-menu somewhere. Maybe we should
> have a Geeky Stuff menu, but putting it under status probably makes sense.
>
> > Configuration
>
> You are not subdividing this? Security levels have a page of their own
> already essentially... OTOH we could keep the current
> seclevels/simple/advanced layout that you objected to...
>
> > Plugins (if required)
> > => Plugin 1
> > => Plugin 2
> > => Plugin 3
>
> We need a way to load official plugins, with a list which explains what
> they do, as well as being able to use current plugins, update plugins etc.
> Some plugins integrate on the web interface, some are so geeky that we
> don't normally want to visit them (e.g. UPnP and JSTUN should be under
> Status) ...
>
Agreed on last point. The loading of plugins has been explained below.
I'm not sure that we understand "integrate on the web interface" the same way,
so I'll explain how I see this :
XMLLibrarian for instance doesn't need anything more than the search field on
the browse freenet page. It shouldn't have an interface at all. The
configuration is made through the Configuration/plugin page.
A plugin like XMLSpider however, doesn't integrate on the web interface : so
there should be a specific menu item for it (under the Plugins/XMLSpider menu).
The configuration though should still be made through the Configuration/plugin
page (for consistency).
> > ?.
> >
> > Managing the node :
> >
> > A always seeable (sorry for new words...) button 'Shutdown the node' and
> > 'Restart the node'
>
> You want to encourage people to shut down? IMHO the best way to do that is
> with a system tray icon.
>
Hum, in all application you can always exit the application in one click. I
know freenet needs people to run it as long as they can, but hidding the
shutdown button is not a solution (we don't want to force them to run freenet,
do we ? ;) )
> > Mode switching :
> >
> > Idem with : 'Switch to {mode=simple?advanced:simple} mode'
>
> Don't we have that now? You just want it to persist between pages?
>
Yes, the switch should be global, and outside the content section of the page.
I also propose to have only one button/link : if we are currently in simple
mode, just show switch to advanced mode, and vice versa. Like a real switch.
> > #Details :
> >
> > ##Freesites :
> >
> > ###Browse Freenet :
> >
> > if XMLLibrarian plugin is loaded, show the search freenet field, else,
> > show a message like : 'if you want to search freesites, you have to load
> > the XMLLibrarian plugin' followed by a button 'Load the plugin'
>
> Agreed, the warning that XMLLibrarian isn't loaded is not very helpful.
>
> > Then show bookmarks. If a bookmark is updated, highlight it.
>
> Agreed, we need to indicate that a bookmark is updated within the Browse
> Freenet page, without relying on alerts.
>
> > That's all.
> >
Ok, here I should have read my post again before sending it :
We should also have a field 'Visit a freesite' in which we can put a freesite
URI. (well, like fetch a key, instead that I thought that fetch a key was
automaticaly adding the key to the global queue)
> > ###Insert your freesite :
> >
> > two solutions :
> >
> > not displaying it until we have a plugin for that
> >
> > or display a message like 'This feature is not yet available. Please use
> > ?jSite / Thingamablog /
> > the-other-freesite-manager-I-don't-remember-the-name? instead.'
> > Possibility to add some instructions, like how to make a freesite
> > available for all.
>
> Hmmm, not a bad idea.
>
> > ##Filesharing :
> >
> > On both pages, at the exact same place :
> >
> > Show the number of current downloads and uploads.
>
> And the total size, surely?
>
Ah, yes. The aim here is to have a ui that looks a bit like a very simple
filesharing client, so we should always see a very short summary.
We could add global dl/ul related bitrate (i.e. the sum of all per dl/ul
bitrate, not the global bitrate for all requests), but I don't know if it's
easily feasable. In the same way, we could show the current bitrate per dl/ul
in the appropriate page (instead of just the progression)
> > ###Downloads :
> >
> > Field bulk download;
>
> What does that mean?
On the current downloads & upload page, there is a field 'bulk download'. Just
reuse it here.
>
> > Show the progress of downloads.
> > Propose to clear all the finished downloads.
>
> Possibly. One problem is it is possible to have downloads to temporary
> space, clearing them will actually *delete the data* so that it is no
> longer accessible. Whereas downloads to disk don't have this problem.
> However, you can only add downloads to disk through fproxy. IMHO we will
> still need to show the two kinds of downloads separately, and we will
> probably want to show finished downloads separately to in-progress
> downloads.
>
Ok, I didn't thought about that. Separate the two kinds of downloads is not a
bad idea.
> > Propose to clear or stop the downloads one-by-one (as now).
>
> Yes.
>
> > Add a checkbox to all downloads, and propose and action for the selected
> > dl (like in the connection to friends page).
>
> For selective deletion? Wouldn't it be better to have a "Delete some
> downloads" button or something that puts in the checkboxes? I mean in terms
> of UI obviousness?
>
Hum, I don't know. For me it seems obvious that when you have checkbox before
an item it's for selection, but it might be confusing for people who aren't
familiar with webui. So, I don't know. We should experiment on this point, and
ask users.
> > ###Uploads :
> >
> > File :
> > Field 'Path' + Button browse.
> > Checkbox : upload through the browser
>
> This is possible with javascript. Without javascript we should show both
> versions, with an explanation.
>
Ok, I thought it would be without javascript. Too bad, it would have made
things clearer.
> > Insert as :
> > * CHK : explain what it is
> > * SSK/USK : idem
> > * KSK : idem + ask for the name
>
> Agreed, some self-documentation here is helpful, although it would make the
> form take up more space.
I don't think space is a scarce ressource here. So it shouldn't be much of a
problem (besides, the explaination should fit in one or two lines)
Oh, and I almost forget :
we should have a distinct 'insert' button (in the current page, the button is
on the same line than the browse button iirc)
>
> > Insertion progress
> >
> > ##Talking :
> >
> > see ?insert your freesite?
> >
> > ##Status :
> >
> > ###Messages :
> > as it is;
> >
> > ###Connections :
> >
> > Number of connections : X
> > Friends : Y
> > Strangers : Z
> >
> > Details :
> >
> > Friends details : as it is
> > Strangers details : idem
> >
> > Add a friend : (I'm not sure wether we should have a page for that or do
> > that here)
>
> We should probably have a page under the Friends top-level menu for adding
> a friend, yes. It could explain noderefs and have various options for easy
> introduction that we haven't written yet.
>
> > Your darknet ref :
> >
> > Don't show the opennet ref : we don't need it, do we ?
>
> We don't show it on simple mode. We do need it for some advanced purposes,
> notably becoming a seednode.
>
Ok.
> > ###Statistics :
> >
> > sub-menu :
> >
> > node related things : (JVM + node version + datastore)
> > bandwith : bandwith usage + number of bits dl/ul
> > misc : cpu, threads, generate thread dump, etc.
>
> Agreed, we should split this up. But it's not important IMHO. Also, it's
> not a top level menu item, and we probably *don't* want the complications
> of three level menus.
>
We can do this very simply. We just need to put the links to all statistics
category page on top of each statistics page. I don't know if I'm clear, so a
bit of html :
Category1.html :
[...]
<a href="category1.html">Category 1</html> - <a href="category2.html">Category
2</html> - ...
<h1>Category 1</h1>
<p>...</p>
Category2.html :
[...]
<a href="category1.html">Category 1</html> - <a href="category2.html">Category
2</html> - ...
<h1>Category 2</h1>
<p>...</p>
With this solution, there is no third level menu. The links are *in* the
contents section of the page.
> > ##Configuration :
> >
> > sub-menus :
> >
> > one per category (+ security level);
>
> This may make sense, although some categories are only of interest to
> geeks. In which case I guess they should only show up in advanced mode...
>
Agreed.
> > javascript could help here : we can keep in memory the changes in the
> > configuration and have a global 'apply' button.
>
> Possibly. And ask the user when they go to a different page.
>
> > + plugins :
> >
> > this interface is just to add plugins and configure them. Plugins should
> > integrate in the ui. If not, they're put in the plugins menu.
> >
> > So :
> >
> > a list of all official plugin with checkbox (already added plugins have a
> > checked checkbox) + button configure (greyed if the plugin is not added).
> >
> > 'apply' button : all unchecked plugin are removed if they were previously
> > activated, all checked plugins are added.
> >
> > Field add a plugin from a uri (local, web, or freenet) : parse the uri to
> > see which case it is, don't let the user do that for you. + button 'add'
> > (add the plugin to the list, checked)
>
> Something like that yeah.
>
> > I think that's all.
> >
> > Comments are *very* welcome of course :)
>
> On Friday 22 May 2009 18:58:02 Ian Clarke wrote:
> > This is exactly the kind of UI review we need.
> >
> > If nobody disagrees, I suggest that you start filing bug reports in
> > mantis with specific suggestions about how to rectify each of these UI
> > bugs.
> >
> > Ian.
>
> Agreed, most of this should be filed as bugs. But the one thing on which
> everything depends is sub-menus, we need to solve that soon.
