Le 19 nov. 2010 19:16, Matthew Toseland <[email protected]> a
écrit :
On Saturday 13 November 2010 01:16:57 [email protected] wrote:
> 2010/11/11 Matthew Toseland [email protected]>:
> > On Thursday 11 November 2010 00:26:37 [email protected] wrote:
> >> 2010/11/10 Matthew Toseland [email protected]>
> >>
> >> > On Saturday 06 November 2010 19:39:09 [email protected] wrote:
> >> > > 2010/11/6 Ian Clarke [email protected]>
> >> > >
> >> > > > On Sat, Nov 6, 2010 at 12:24 PM, Matthew Toseland
> >> > > > [email protected]> 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?
_______________________________________________
Devl mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/devl
