Le 19 nov. 2010 19:16, Matthew Toseland <toad at amphibian.dyndns.org> a ?crit : > On Saturday 13 November 2010 01:16:57 cvollet at gmail.com wrote:
> > 2010/11/11 Matthew Toseland toad at amphibian.dyndns.org>: > > > On Thursday 11 November 2010 00:26:37 cvollet at gmail.com wrote: > > >> 2010/11/10 Matthew Toseland toad at amphibian.dyndns.org> > > >> > > >> > On Saturday 06 November 2010 19:39:09 cvollet at gmail.com wrote: > > >> > > 2010/11/6 Ian Clarke ian at locut.us> > > >> > > > > >> > > > On Sat, Nov 6, 2010 at 12:24 PM, Matthew Toseland > > >> > > > toad at amphibian.dyndns.org> wrote: > > >> > > > > > >> > > >> Awesome. I'm having difficulty viewing the svg's due to local > > >> > technical > > >> > > >> problems. It might save me time if you could post JPEGs or > something? > > >> > > >> > > >> > > > > > >> > > > +1 for jpeg or png, I've tried viewing these in several > different apps > > >> > and > > >> > > > they look screwed up in all of them. > > >> > > > > > >> > > > Yep, dunno why I didn't do that directly... (and svg should > open fine > > >> > in > > >> > > inkscape). > > >> > > Anyway, see attached. > > >> > > > >> > Ooooh, interesting. > > >> > > > >> > Thanks, wasn't sure it would be appreciated. > > >> > > >> > First, IMHO passwords should be optional. Maybe even configurable > based on > > >> > initial seclevels. We are not going to have separate client layer > databases > > >> > for each user, since we want everyone's downloads to work > simultaneously - > > >> > and most nodes will have one user, who may have multiple accounts > for eg > > >> > different chat pseudonyms. If passwords are disabled, we can have > a simple > > >> > dropdown login. > > >> > > > >> I'm not sure we should allow password-less accounts, maybe it makes > sense > > >> for users who don't really care about their anonymity though. > > > > > > Eh? It's their own computer! > > > > > > The only reason to have a password is: > > > 1) To encrypt the downloads, uploads, and client-cache separately for > each account. This is an option but is quite heavyweight. > > > 2) In case others have access without having root access ie for > multi-user systems. > > > > > > Many people won't need either of these things. > > > > > Hum, true. Maybe it's best to leave the password as an option then. > > >> We should add > > >> a warning if they want to have a non protected access to their > account. > > >> Regarding the one-account/one-client-layer I agree. But one user > shouldn't > > >> be able to eavesdrop another user's download. > > > > > > Anyone who has physical/root access can see all the accounts very > easily, unless we have separate encrypted client layer per account. > Which might be a good idea, as long as you can leave your other accounts > running when using a different one, as was recently pointed out. > > >> > > >> What do you mean by dropdown login? If it's presenting user with > different > > >> possible login, I disagree, we should let the browser manage that. > Like in > > >> linux, if you don't know the username, well, too bad. Or, we could > add > > >> another layer => account => identity. Dunno if it makes sense. > > > > > > I was just thinking of making it easy, whatever... > > Well, yeah, but if you share your computer, one can easily log in. If > > we let the user decide if he wants to remember the login, then it's > > his choice and his problem if someone log into his account. > > >> > > >> > Second, I like the idea of having a traffic light for darknet vs > opennet vs > > >> > connection problems. I'm happy to defer to folk who better > understand > > >> > usability on how to deal with system notifications, just as long > as we do > > >> > deal with them. > > >> > > > >> I don't have in mind any notification that can't be addressed to a > specific > > >> group of users. Do you have something in mind. (btw, and I don't > know why I > > >> didn't ask before, nor why I do ask now, but if someone could > forward this > > >> mockup to FMS/Freetalk/Frost, and have feedback from community (even > if this > > >> doesn't concern the apps currently covered by the mockup), it would > be great > > >> :) > > > > > > I'm not following. Most alerts concern Freenet itself. Some concern > eg downloads, bookmarks; we can move them. And there's a difference > between notifications/events and alerts; we can have pop-up notifications > in the system tray for things like completed downloads? > > Hum, ok, so in Freenet UI notifications for alerts (users have to > > close them manually) > Yes, but I'm not sure where we want to show them, probably depends on > urgency? > > and system tray notifications for events > > (auto-hide after some seconds) ? > Yes, although we may want to aggregate events into alerts (as with > completed downloads), or have an event log on a page the user can visit > if they want to? A log page seems good. We also need to highlight the changed elements in the web app itself. The only thing that bothers me, is that there is no logical link between the notification in the systray and the event log page. So, maybe, we're doing it wrong; - the standalone app here is Freenet, so the user needs to be able to know that there is a problem with it even if the interface is not displayed. So, we use systray notification for events/alerts coming from Freenet itself (dunno if it works with remote systems though). We also add them in the log page (we can do like azureus (didn't use vuze, so I don't know how they do now), and allow the user to filter the log: freenet related log / downloads / mails / ...). - the web apps maybe don't need notifications in the systray? I mean, when I use gmail, except if I have it configured in a standalone app, I don't see when I have a new message if I don't have gmail opened (same thing goes for facebook, or any webapp). For those notifications, we could use the right part of the menu, where we show the logged in user. We could add an avatar, and show the notifications when clicking on it when they're hidden, and under it when we display them. We add a link at the bottom to the event log page, or when we click on a notification (much like now). Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20101119/907c1942/attachment.html>
