On Saturday 23 May 2009 01:20:23 Cl?ment wrote:
> 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)
Okay, so you just want to change the name of the box from "Fetch a key (CHK,
USK, SSK)" ... to what?
>
> > > ?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.
It is highly unlikely that a newbie will visit the stats page, or remember
anything they see there.
>
> > > ?Current Activity? : idem
> >
> > Fair point.
I have deleted "Current Activity".
> >
> > > #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.
Okay. It should be under a submenu.
>
> > 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.
Who is going to implement it? I'm not a CSS wizard by any means...
Caco_Patane send me a draft that would work with one of the themes, but I don't
think it would work with the others. We need to modify all of the themes to
support sub-menus. How exactly can be on a per-theme basis, they can be CSS
popups or they can be a horizontal menu to go with the existing vertical or
they can just be another horizontal menu under a horizontal menu etc. But
somebody needs to do the work. Save the HTML from the homepage, modify it to
have submenus, modify each CSS so that it works.
>
> > > #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.
We might want a separate sub-page for messages to/from Friends, or we might
want to show more newbie-friendly info for each Friend in a more verbose way
rather than a table.
>
> > > 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).
Well, we do need the totals, don't we?
>
> > > #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)
Even with the links ... of course the category names aren't very helpful...
>
> > > 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).
Ok, file a bug about this. But there is quite a bit that needs to be global and
always displayed:
- Simple vs advanced mode.
- Maybe the language setting.
- Summary of user-alerts.
- Security levels.
We probably need to rethink this!
>
> > > 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.
Agreed, somebody needs to implement the CSS changes.
> > > 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...
Maybe so. The number of messages can vary though... The immediate priority is
just to reduce the number.
>
> > > => 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).
It is *very* useful if you set network security to HIGH or MAXIMUM, it is also
useful if you want to chat with your peers. And yes that means a separate page
for adding Friends.
>
> > > => 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.
Exactly.
> 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).
Hmmm, maybe. Why not just access its configuration through the plugin page?
Unless it's something really big and important like Freetalk.
>
> > > ?.
> > >
> > > 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 ? ;) )
Hence a system tray icon. And it's two clicks with most applications - one to
confirm.
>
> > > 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.
It IS like a switch, only one of the toggles is a link, the other one is just
highlighted. And it's going to take up a load of horizontal space anyway. So
how exactly would you change its UI, apart from making it persistent?
>
> > > #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.
Done, although currently I link to the plugins page rather than having a load
the plugin button; file a bug if you want.
> >
> > > 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)
Won't people mistake it for a search box? I'm not sure that "Visit a freesite"
is enough? "Visit a freesite (if you know the key)" ???
>
> > > ###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)
We could ... or an ETA. It's likely to be rather disappointing either way,
would it be an improvement?
>
> > > ###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.
Well, javascript is now on by default, we should use it where possible.
>
> > > 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)
Yeah ... but it means the box is going to take up a *significant* chunk of
space, are you sure this isn't a problem? Well, with submenus, it could be a
separate page anyway...
> > > ###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 :
You mean like we do on the Configuration page which you find difficult to use?
If it's bad there then it's bad here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090523/0543f38c/attachment.pgp>
