[freenet-dev] Hello

[Matthew Toseland]

On Thursday 11 Aug 2011 06:43:16 Volodya wrote:
> You have serious misconseptions about the way freenet operates, i believe.
> 
> 1. You do not connect to the nodes that have the stuff you need, you build a
> chain of the nodes (so to speak), and therefore you do not know exactly who 
> has
> that block of furry porn you are looking for, only that one of your friends 
> (or
> stranger opennet peers) has a connection which has a connection... to the 
> stuff.
> Think of the social networks, it's a good model.
> 
> 2. If you will have separate stores the way you describe, then you would have 
> to
> do several things things: 1. You would have to declare the type of content you
> are distributing. 2. Know that your node is propagating a specific type of
> content. 3. When requesting content you would have to declare that you want 
> it.
> This leads to many issues, for example, if furry porn is illegal in Vatican 
> city
> for everybody but muslims and mormons, and i run a node there and i'm not a
> muslim nor a mormon, then when the pope inspects my computer and sees
> 'cache-furryporn.bin' i will not have plausible deniability, because i could
> have been deleting that file or could have altered the code of freenet to
> disallow requests to be passed which are for furryporn audience. Also when one
> of my friends gets compromised by l33t cardinal's h at x0r skills then his 
> node
> will record the fact that i have been making a lot of requests for furry porn
> lately, and that is just not very nice.
> 
> The point of freenet is (and must be) that nobody, not even you, knows what
> information you are passing to your peers. This way if somebody asks you "What
> is in your datastore?" you laugh at them because that is something you do not 
> know.
> 
>   - Volodya

Of course, it is possible to collect keys (e.g. by spidering the freesites and 
watching the forums) and therefore be able to identify that this or that block 
is part of this or that file. But in general, you can't immediately decrypt or 
identify the content in your datastore (because you don't have the decryption 
keys unless you have the freenet URIs e.g. CHK at ...) - at least not without a 
lot of work. The objective is "plausible deniability": You don't know what is 
in your datastore, or what you are forwarding. Also, the fact that blocks of 
data are essentially indistinguishable probably makes some attacks harder. 
Although in some cases it makes them easier - dividing a big file into many 
small chunks means there might be more samples for an attacker in some cases. 
Fixed sizes are more for simplicity...

Have a look at our website and/or wiki for more details.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

Re: [freenet-dev] Hello

[Matthew Toseland]

On Thursday 11 Aug 2011 06:43:16 Volodya wrote:
 You have serious misconseptions about the way freenet operates, i believe.
 
 1. You do not connect to the nodes that have the stuff you need, you build a
 chain of the nodes (so to speak), and therefore you do not know exactly who 
 has
 that block of furry porn you are looking for, only that one of your friends 
 (or
 stranger opennet peers) has a connection which has a connection... to the 
 stuff.
 Think of the social networks, it's a good model.
 
 2. If you will have separate stores the way you describe, then you would have 
 to
 do several things things: 1. You would have to declare the type of content you
 are distributing. 2. Know that your node is propagating a specific type of
 content. 3. When requesting content you would have to declare that you want 
 it.
 This leads to many issues, for example, if furry porn is illegal in Vatican 
 city
 for everybody but muslims and mormons, and i run a node there and i'm not a
 muslim nor a mormon, then when the pope inspects my computer and sees
 'cache-furryporn.bin' i will not have plausible deniability, because i could
 have been deleting that file or could have altered the code of freenet to
 disallow requests to be passed which are for furryporn audience. Also when one
 of my friends gets compromised by l33t cardinal's h@x0r skills then his node
 will record the fact that i have been making a lot of requests for furry porn
 lately, and that is just not very nice.
 
 The point of freenet is (and must be) that nobody, not even you, knows what
 information you are passing to your peers. This way if somebody asks you What
 is in your datastore? you laugh at them because that is something you do not 
 know.
 
   - Volodya

Of course, it is possible to collect keys (e.g. by spidering the freesites and 
watching the forums) and therefore be able to identify that this or that block 
is part of this or that file. But in general, you can't immediately decrypt or 
identify the content in your datastore (because you don't have the decryption 
keys unless you have the freenet URIs e.g. CHK@...) - at least not without a 
lot of work. The objective is plausible deniability: You don't know what is 
in your datastore, or what you are forwarding. Also, the fact that blocks of 
data are essentially indistinguishable probably makes some attacks harder. 
Although in some cases it makes them easier - dividing a big file into many 
small chunks means there might be more samples for an attacker in some cases. 
Fixed sizes are more for simplicity...

Have a look at our website and/or wiki for more details.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello

[Volodya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

You have serious misconseptions about the way freenet operates, i believe.

1. You do not connect to the nodes that have the stuff you need, you build a
chain of the nodes (so to speak), and therefore you do not know exactly who has
that block of furry porn you are looking for, only that one of your friends (or
stranger opennet peers) has a connection which has a connection... to the stuff.
Think of the social networks, it's a good model.

2. If you will have separate stores the way you describe, then you would have to
do several things things: 1. You would have to declare the type of content you
are distributing. 2. Know that your node is propagating a specific type of
content. 3. When requesting content you would have to declare that you want it.
This leads to many issues, for example, if furry porn is illegal in Vatican city
for everybody but muslims and mormons, and i run a node there and i'm not a
muslim nor a mormon, then when the pope inspects my computer and sees
'cache-furryporn.bin' i will not have plausible deniability, because i could
have been deleting that file or could have altered the code of freenet to
disallow requests to be passed which are for furryporn audience. Also when one
of my friends gets compromised by l33t cardinal's h at x0r skills then his node
will record the fact that i have been making a lot of requests for furry porn
lately, and that is just not very nice.

The point of freenet is (and must be) that nobody, not even you, knows what
information you are passing to your peers. This way if somebody asks you "What
is in your datastore?" you laugh at them because that is something you do not 
know.

  - Volodya



On 08/11/2011 01:17 AM, Zurc wrote:
> Hi all, I've been talking back and forth with Toad mostly and I sent him this
> then decided it'd be better to send it to everyone and join the party, I'm
> new-ish to programming but data encryption was my speciality in the DoD while 
> I
> worked there, additionally I'm familiar with digital exploitation. I don't 
> work
> for the man anymore, i got booted but i liked what I was doing and if they 
> arent
> going to keep me i'll go somewhere else where i can be as disrespectful and
> belligerent as i want without fearing almighty retribution. Anyway, I thought
> I'd shoot an idea I had about compartmentalizing the freenet cache so that 
> it's
> easier for computers to find information and also see if my understanding of
> freenet is correct
> 
> (*correct me where I'm wrong*)
> 
> Lets say you have 10 nodes that are all connected to each other via Freenet, 
> and
> these nodes are all sharing information
> 
> lets say I'm node 1 and you are node 2 and I just requested mad Furry porn.
> 
> the request is pushed to the other clients, and the desired file is found on 3
> of the 10 nodes, yours being one of them.
> 
> From what I understand my node connects to the three nodes with the furry 
> pron i
> wants and starts downloading it building the file on my computer by taking
> peices of the file from the three computers I'm connected to.
> 
> I can imagine it takes quite a bit of processing to figure out which of those
> ten computers had the furry porn because the cache on each of the computers is
> 30ish gig big, so thats 300 gigabytes worth of not wanted information my
> computer has to go through to get the 150 MB series that I want. So what if
> instead of having one cache made up of all information on 10 seperate 
> computers
> you had seperate caches for different kinds of information on each computer
> organized in such a way that freenet knows which compartment to open to get 
> the
> requested info. It seems like you could make it so that users can shrink and
> increases the size of their local cache depending on what they intend on
> downloading. Obviously you wouldnt be literal with it, you wouldnt have a 
> cache
> devoted to kiddie porn or a cache devoted to ill3gal war3z. you'd have a cache
> devoted to media and another to program files. You might even make it so that
> users can change the prioritys of the different caches along with the size.
> 
> thoughts?
> 
> 
> 
> ___
> Devl mailing list
> Devl at freenetproject.org
> http://freenetproject.org/cgi-bin/mailman/listinfo/devl


- -- 
http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast

 "None of us are free until all of us are free."~ Mihail Bakunin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOQ2vzAAoJENW9VI+wmYasi8oH/01ujHIX9Nn7vga1cJRti0fk
5GjxgAJuTWqwEcIFckKl1XgxdQJ0DXN34unKN6nPhqC7epyH3xvABEZFQquNvARM
eAUQtKFvla0a5ZoFA2CVgYbpShqP5QseJxS4tN+5RVDZPecS/A0DGdhTMKvD1Qld
Y48Jo/UHcFL9zrugQnQmlT5ZmKGCu+P4VuO2zRhF0FcfVxmPd97yKOO58BdDetK9
St4W3n/uzPfwoFQN1Fui2zM6DZ/e2pa09gRUHF3+6m2Eh3x8gIH/6jRJ//BqN6zv

[freenet-dev] Hello

[Arne Babenhauserheide]

Hi Zurc, 

Welcome to Freenet!

Am Mittwoch, 10. August 2011, 14:17:22 schrieb Zurc:
> I can imagine it takes quite a bit of processing to figure out which of 
> those ten computers had the furry porn because the cache on each of the 
> computers is 30ish gig big, so thats 300 gigabytes worth of not wanted 
> information my computer has to go through to get the 150 MB series that 
> I want.

I think Toad fixed that problem with store-io:
? https://emu.freenetproject.org/pipermail/devl/2011-July/001659.html

Best wishes, 
Arne
-- 
Ein Mann wird auf der Stra?e mit einem Messer bedroht. 
Zwei Polizisten sind sofort da und halten ein Transparent davor. 

"Illegale Szene. Niemand darf das sehen."

Der Mann wird ausgeraubt, erstochen und verblutet, 
denn die Polizisten haben beide H?nde voll zu tun. 

Willkommen in Deutschland. Zensur ist sch?n. 
  ( http://draketo.de/stichwort/zensur )

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] Hello

[Zurc]

Hi all, I've been talking back and forth with Toad mostly and I sent him 
this then decided it'd be better to send it to everyone and join the 
party, I'm new-ish to programming but data encryption was my speciality 
in the DoD while I worked there, additionally I'm familiar with digital 
exploitation. I don't work for the man anymore, i got booted but i liked 
what I was doing and if they arent going to keep me i'll go somewhere 
else where i can be as disrespectful and belligerent as i want without 
fearing almighty retribution. Anyway, I thought I'd shoot an idea I had 
about compartmentalizing the freenet cache so that it's easier for 
computers to find information and also see if my understanding of 
freenet is correct

(*correct me where I'm wrong*)

Lets say you have 10 nodes that are all connected to each other via 
Freenet, and these nodes are all sharing information

lets say I'm node 1 and you are node 2 and I just requested mad Furry porn.

the request is pushed to the other clients, and the desired file is 
found on 3 of the 10 nodes, yours being one of them.

 From what I understand my node connects to the three nodes with the 
furry pron i wants and starts downloading it building the file on my 
computer by taking peices of the file from the three computers I'm 
connected to.

I can imagine it takes quite a bit of processing to figure out which of 
those ten computers had the furry porn because the cache on each of the 
computers is 30ish gig big, so thats 300 gigabytes worth of not wanted 
information my computer has to go through to get the 150 MB series that 
I want. So what if instead of having one cache made up of all 
information on 10 seperate computers you had seperate caches for 
different kinds of information on each computer organized in such a way 
that freenet knows which compartment to open to get the requested info. 
It seems like you could make it so that users can shrink and increases 
the size of their local cache depending on what they intend on 
downloading. Obviously you wouldnt be literal with it, you wouldnt have 
a cache devoted to kiddie porn or a cache devoted to ill3gal war3z. 
you'd have a cache devoted to media and another to program files. You 
might even make it so that users can change the prioritys of the 
different caches along with the size.

thoughts?

-- next part --
An HTML attachment was scrubbed...
URL: 

[freenet-dev] Hello

[Zurc]

Hi all, I've been talking back and forth with Toad mostly and I sent him 
this then decided it'd be better to send it to everyone and join the 
party, I'm new-ish to programming but data encryption was my speciality 
in the DoD while I worked there, additionally I'm familiar with digital 
exploitation. I don't work for the man anymore, i got booted but i liked 
what I was doing and if they arent going to keep me i'll go somewhere 
else where i can be as disrespectful and belligerent as i want without 
fearing almighty retribution. Anyway, I thought I'd shoot an idea I had 
about compartmentalizing the freenet cache so that it's easier for 
computers to find information and also see if my understanding of 
freenet is correct


(*correct me where I'm wrong*)

Lets say you have 10 nodes that are all connected to each other via 
Freenet, and these nodes are all sharing information


lets say I'm node 1 and you are node 2 and I just requested mad Furry porn.

the request is pushed to the other clients, and the desired file is 
found on 3 of the 10 nodes, yours being one of them.


From what I understand my node connects to the three nodes with the 
furry pron i wants and starts downloading it building the file on my 
computer by taking peices of the file from the three computers I'm 
connected to.


I can imagine it takes quite a bit of processing to figure out which of 
those ten computers had the furry porn because the cache on each of the 
computers is 30ish gig big, so thats 300 gigabytes worth of not wanted 
information my computer has to go through to get the 150 MB series that 
I want. So what if instead of having one cache made up of all 
information on 10 seperate computers you had seperate caches for 
different kinds of information on each computer organized in such a way 
that freenet knows which compartment to open to get the requested info. 
It seems like you could make it so that users can shrink and increases 
the size of their local cache depending on what they intend on 
downloading. Obviously you wouldnt be literal with it, you wouldnt have 
a cache devoted to kiddie porn or a cache devoted to ill3gal war3z. 
you'd have a cache devoted to media and another to program files. You 
might even make it so that users can change the prioritys of the 
different caches along with the size.


thoughts?

___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello

[Arne Babenhauserheide]

Hi Zurc,

Welcome to Freenet!

Am Mittwoch, 10. August 2011, 14:17:22 schrieb Zurc:
 I can imagine it takes quite a bit of processing to figure out which of
 those ten computers had the furry porn because the cache on each of the
 computers is 30ish gig big, so thats 300 gigabytes worth of not wanted
 information my computer has to go through to get the 150 MB series that
 I want.

I think Toad fixed that problem with store-io:
→ https://emu.freenetproject.org/pipermail/devl/2011-July/001659.html

Best wishes,
Arne
--
Ein Mann wird auf der Straße mit einem Messer bedroht.
Zwei Polizisten sind sofort da und halten ein Transparent davor.

Illegale Szene. Niemand darf das sehen.

Der Mann wird ausgeraubt, erstochen und verblutet,
denn die Polizisten haben beide Hände voll zu tun.

Willkommen in Deutschland. Zensur ist schön.
  ( http://draketo.de/stichwort/zensur )



signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello this is a message about freenet

[Matthew Toseland]

This is another message.
-- 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: 

[freenet-dev] Hello this is a message about freenet

[Matthew Toseland]

This is another message.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://osprey.vm.bytemark.co.uk/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello Freenet (& design feedback)

[brendan]

Go Team! The new site is a very exciting step forward.

Matthew, I agree with you that any pages, like the http:// 
freenetproject.org/translation.html that have no content should either
1: be removed and have referring links and copy removed
or
2: Have place holder copy on the page stating something like "We're  
still working on this area." and perhaps add something like "Join or  
mailing to be notified of future site updates."

I would recommend #2, and add that the page should not be totally  
white. It should look like the rest of the site, but with the  
placeholder content popped into the main content area.

-Brendan



On Jul 31, 2009, at 3:00 PM, Matthew Toseland wrote:

> On Monday 20 July 2009 17:08:50 brendan at artvote.com wrote:
>> Hi All,
>> Over the past couple months I've been speaking with Ian about your  
>> fascinating project and recently, he's asked me to give feedback  
>> on the new site design so I've included a previous email  
>> addressing that below.
>> Looking forward to more conversations with each of you!
>> -Brendan
>> p.s. Here's my brief bio: I am a digital product designer,  
>> interested in interactive design, information architecture, user  
>> experience, business strategy, and generally making life easier  
>> and more fun.
>>
>> //
>>
>> Hi Ian,
>>
>>  Overall, I think that this visual design is a nice step forward.  
>> The navigation is clearer, and having a single column structure  
>> gives you room for a left hand navigation down the road on lower- 
>> level pages, should you need it.
>>
>>  As far as color, do you have sense of what you want the brand  
>> colors to be? It looks like the new release of the app, and the  
>> logo mark, are blue. Perhaps consider having a blue-tone color  
>> theme rather that the black grey theme. Having the header black  
>> makes it feel "dark". I would be mindful of the connotations that  
>> "darkness" has (good and bad). Might be interesting to see a  
>> lighter treatment. Perhaps blue and grey of beige?
>>
>>  (As far as information design and the presentation of the content  
>> on the pages, see the comments below on structure and content. It  
>> makes sense to address the larger questions prior to focusing the  
>> presentation of page-level content.)
>>
>>  That's pretty much my first blush on design.
>>
>>  I think there are a couple quick-wins that are usability related,  
>> that I've included below (1&2).
>>
>>  PAGE: Home page:
>>  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
>>
>>  1. Since you've opted to have the app installer automatically  
>> begin the install after they click (instead of downloading first)  
>> Here are a few preparatory steps you might want to include to  
>> prepare the suer.
>>  Make the label on the button more descriptive and consider adding  
>> a few bullets above the button to describe the installation  
>> process. For instance:
>>  "Getting started is easy! When you install, you'll do the following:
>>
>> ? Download and automatically open the installer
>> ? Set your security preference and connection speed
>> ? Explore the feature through the Getting Started Tutorial"
>>  ["Install Freenet now" = button label]
>>
>>  2. Screenshots are great to have. Consider adding a trigger that  
>> says "Click to View Screenshots" under the one on the right, and  
>> on the destination page, add more screenshots and label what those  
>> screens are. Currently the destination page is just a single  
>> larger screenshot. Add a description telling the user which screen  
>> they are looking at and add additional screens of other parts of  
>> the app beneath it on this page and a link at the bottom to take  
>> the user back to the previous page, the home page.
>>
>>  I like the "Latest News" item. Feels like a 'heartbeat' on the  
>> site. That's good.
>>
>>  Here's some additional food for though regarding content and  
>> structure.
>>
>>  Have a look at panic.com or http://www.panic.com/transmit/ and  
>> check out how they have loads of features on the product page.  
>> Consider having a "product features" page with iconography and a  
>> quick description of each feature. This is a nice way to pay off  
>> your central product 'value proposition' (Ex. "Share, Chat,  
>> Browse. Anonymously. On the Free Network." - Then give a list of  
>> features somewhere on the site that explains this in a bit more  
>> detail.)
>>
>>  Here's a big structure idea. It looks like there are two main  
>> content areas: Content related to the app: And, content related to  
>> the Freenet Project. In the future, restructuring the site, and  
>> making a clear distinction between these two types of content,  
>> could really help the overall UX and usability of the site. This  
>> type of structure would also help a broader audience to self- 
>> segment and get to their desired content more easily.
>>
>>  Best,
>> Brendan
>>
> I have deployed the current website 

Re: [freenet-dev] Hello Freenet ( design feedback)

[brendan]

Go Team! The new site is a very exciting step forward.

Matthew, I agree with you that any pages, like the http:// 
freenetproject.org/translation.html that have no content should either
1: be removed and have referring links and copy removed
or
2: Have place holder copy on the page stating something like We're  
still working on this area. and perhaps add something like Join or  
mailing to be notified of future site updates.

I would recommend #2, and add that the page should not be totally  
white. It should look like the rest of the site, but with the  
placeholder content popped into the main content area.

-Brendan



On Jul 31, 2009, at 3:00 PM, Matthew Toseland wrote:

 On Monday 20 July 2009 17:08:50 bren...@artvote.com wrote:
 Hi All,
 Over the past couple months I've been speaking with Ian about your  
 fascinating project and recently, he's asked me to give feedback  
 on the new site design so I've included a previous email  
 addressing that below.
 Looking forward to more conversations with each of you!
 -Brendan
 p.s. Here's my brief bio: I am a digital product designer,  
 interested in interactive design, information architecture, user  
 experience, business strategy, and generally making life easier  
 and more fun.

 //

 Hi Ian,

  Overall, I think that this visual design is a nice step forward.  
 The navigation is clearer, and having a single column structure  
 gives you room for a left hand navigation down the road on lower- 
 level pages, should you need it.

  As far as color, do you have sense of what you want the brand  
 colors to be? It looks like the new release of the app, and the  
 logo mark, are blue. Perhaps consider having a blue-tone color  
 theme rather that the black grey theme. Having the header black  
 makes it feel dark. I would be mindful of the connotations that  
 darkness has (good and bad). Might be interesting to see a  
 lighter treatment. Perhaps blue and grey of beige?

  (As far as information design and the presentation of the content  
 on the pages, see the comments below on structure and content. It  
 makes sense to address the larger questions prior to focusing the  
 presentation of page-level content.)

  That's pretty much my first blush on design.

  I think there are a couple quick-wins that are usability related,  
 that I've included below (12).

  PAGE: Home page:
  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html

  1. Since you've opted to have the app installer automatically  
 begin the install after they click (instead of downloading first)  
 Here are a few preparatory steps you might want to include to  
 prepare the suer.
  Make the label on the button more descriptive and consider adding  
 a few bullets above the button to describe the installation  
 process. For instance:
  Getting started is easy! When you install, you'll do the following:

 · Download and automatically open the installer
 · Set your security preference and connection speed
 · Explore the feature through the Getting Started Tutorial
  [Install Freenet now = button label]

  2. Screenshots are great to have. Consider adding a trigger that  
 says Click to View Screenshots under the one on the right, and  
 on the destination page, add more screenshots and label what those  
 screens are. Currently the destination page is just a single  
 larger screenshot. Add a description telling the user which screen  
 they are looking at and add additional screens of other parts of  
 the app beneath it on this page and a link at the bottom to take  
 the user back to the previous page, the home page.

  I like the Latest News item. Feels like a 'heartbeat' on the  
 site. That's good.

  Here's some additional food for though regarding content and  
 structure.

  Have a look at panic.com or http://www.panic.com/transmit/ and  
 check out how they have loads of features on the product page.  
 Consider having a product features page with iconography and a  
 quick description of each feature. This is a nice way to pay off  
 your central product 'value proposition' (Ex. Share, Chat,  
 Browse. Anonymously. On the Free Network. - Then give a list of  
 features somewhere on the site that explains this in a bit more  
 detail.)

  Here's a big structure idea. It looks like there are two main  
 content areas: Content related to the app: And, content related to  
 the Freenet Project. In the future, restructuring the site, and  
 making a clear distinction between these two types of content,  
 could really help the overall UX and usability of the site. This  
 type of structure would also help a broader audience to self- 
 segment and get to their desired content more easily.

  Best,
 Brendan

 I have deployed the current website redesign, which is essentially  
 Dieppe's work with much feedback from here. It is working, the only  
 problem is the translation page is empty:
 http://freenetproject.org/translation.html

 Should we remove it for 

[freenet-dev] Hello Freenet (& design feedback)

[Clément]

Le vendredi 31 juillet 2009 21:00:45, Matthew Toseland a ?crit :
> On Monday 20 July 2009 17:08:50 brendan at artvote.com wrote:
> > Hi All,
> > Over the past couple months I've been speaking with Ian about your
> > fascinating project and recently, he's asked me to give feedback on the
> > new site design so I've included a previous email addressing that below.
> > Looking forward to more conversations with each of you!
> > -Brendan
> > p.s. Here's my brief bio: I am a digital product designer, interested in
> > interactive design, information architecture, user experience, business
> > strategy, and generally making life easier and more fun.
> >
> > //
> >
> > Hi Ian,
> >
> >  Overall, I think that this visual design is a nice step forward. The
> > navigation is clearer, and having a single column structure gives you
> > room for a left hand navigation down the road on lower-level pages,
> > should you need it.
> >
> >  As far as color, do you have sense of what you want the brand colors to
> > be? It looks like the new release of the app, and the logo mark, are
> > blue. Perhaps consider having a blue-tone color theme rather that the
> > black grey theme. Having the header black makes it feel "dark". I would
> > be mindful of the connotations that "darkness" has (good and bad). Might
> > be interesting to see a lighter treatment. Perhaps blue and grey of
> > beige?
> >
> >  (As far as information design and the presentation of the content on the
> > pages, see the comments below on structure and content. It makes sense to
> > address the larger questions prior to focusing the presentation of
> > page-level content.)
> >
> >  That's pretty much my first blush on design.
> >
> >  I think there are a couple quick-wins that are usability related, that
> > I've included below (1&2).
> >
> >  PAGE: Home page:
> >  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
> >
> >  1. Since you've opted to have the app installer automatically begin the
> > install after they click (instead of downloading first) Here are a few
> > preparatory steps you might want to include to prepare the suer. Make the
> > label on the button more descriptive and consider adding a few bullets
> > above the button to describe the installation process. For instance:
> > "Getting started is easy! When you install, you'll do the following:
> >
> > ? Download and automatically open the installer
> > ? Set your security preference and connection speed
> > ? Explore the feature through the Getting Started Tutorial"
> >  ["Install Freenet now" = button label]
> >
> >  2. Screenshots are great to have. Consider adding a trigger that says
> > "Click to View Screenshots" under the one on the right, and on the
> > destination page, add more screenshots and label what those screens are.
> > Currently the destination page is just a single larger screenshot. Add a
> > description telling the user which screen they are looking at and add
> > additional screens of other parts of the app beneath it on this page and
> > a link at the bottom to take the user back to the previous page, the home
> > page.
> >
> >  I like the "Latest News" item. Feels like a 'heartbeat' on the site.
> > That's good.
> >
> >  Here's some additional food for though regarding content and structure.
> >
> >  Have a look at panic.com or http://www.panic.com/transmit/ and check out
> > how they have loads of features on the product page. Consider having a
> > "product features" page with iconography and a quick description of each
> > feature. This is a nice way to pay off your central product 'value
> > proposition' (Ex. "Share, Chat, Browse. Anonymously. On the Free
> > Network." - Then give a list of features somewhere on the site that
> > explains this in a bit more detail.)
> >
> >  Here's a big structure idea. It looks like there are two main content
> > areas: Content related to the app: And, content related to the Freenet
> > Project. In the future, restructuring the site, and making a clear
> > distinction between these two types of content, could really help the
> > overall UX and usability of the site. This type of structure would also
> > help a broader audience to self-segment and get to their desired content
> > more easily.
> >
> >  Best,
> > Brendan
>
> I have deployed the current website redesign, which is essentially Dieppe's
> work with much feedback from here. It is working, the only problem is the
> translation page is empty: http://freenetproject.org/translation.html
>
> Should we remove it for now?
>
Sure, I just wanted to put an howto for translators there, but well, I don't 
know the translation process. And I'm too busy right now to do it.
> IMHO the new site is an improvement over the old one, especially with the
> big download button. However I'm sure we could further improve it.
Well, there's room for improvment, yes. I can start to work on that after my 
internship, which ends the 18 september. I'll still have a report to 

[freenet-dev] Hello Freenet (& design feedback)

[Zero3]

Matthew Toseland skrev:
> I have deployed the current website redesign, which is essentially Dieppe's 
> work with much feedback from here. It is working, the only problem is the 
> translation page is empty:
> http://freenetproject.org/translation.html
> 
> Should we remove it for now?
> 
> IMHO the new site is an improvement over the old one, especially with the big 
> download button. However I'm sure we could further improve it.

*claps*

I think it is a great improvement! (with room for optimization, as always)

The screenshot is still worse than awful though.

- Zero3

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Monday 20 July 2009 17:08:50 brendan at artvote.com wrote:
> Hi All,
> Over the past couple months I've been speaking with Ian about your 
> fascinating project and recently, he's asked me to give feedback on the new 
> site design so I've included a previous email addressing that below. 
> Looking forward to more conversations with each of you!
> -Brendan
> p.s. Here's my brief bio: I am a digital product designer, interested in 
> interactive design, information architecture, user experience, business 
> strategy, and generally making life easier and more fun. 
> 
> //
> 
> Hi Ian,
>  
>  Overall, I think that this visual design is a nice step forward. The 
> navigation is clearer, and having a single column structure gives you room 
> for a left hand navigation down the road on lower-level pages, should you 
> need it.
>  
>  As far as color, do you have sense of what you want the brand colors to be? 
> It looks like the new release of the app, and the logo mark, are blue. 
> Perhaps consider having a blue-tone color theme rather that the black grey 
> theme. Having the header black makes it feel "dark". I would be mindful of 
> the connotations that "darkness" has (good and bad). Might be interesting to 
> see a lighter treatment. Perhaps blue and grey of beige?
>  
>  (As far as information design and the presentation of the content on the 
> pages, see the comments below on structure and content. It makes sense to 
> address the larger questions prior to focusing the presentation of page-level 
> content.)
>  
>  That's pretty much my first blush on design.
>  
>  I think there are a couple quick-wins that are usability related, that I've 
> included below (1&2).
>  
>  PAGE: Home page:
>  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
>  
>  1. Since you've opted to have the app installer automatically begin the 
> install after they click (instead of downloading first) Here are a few 
> preparatory steps you might want to include to prepare the suer.
>  Make the label on the button more descriptive and consider adding a few 
> bullets above the button to describe the installation process. For instance:
>  "Getting started is easy! When you install, you'll do the following:
>  
> ? Download and automatically open the installer
> ? Set your security preference and connection speed
> ? Explore the feature through the Getting Started Tutorial"
>  ["Install Freenet now" = button label]
>  
>  2. Screenshots are great to have. Consider adding a trigger that says "Click 
> to View Screenshots" under the one on the right, and on the destination page, 
> add more screenshots and label what those screens are. Currently the 
> destination page is just a single larger screenshot. Add a description 
> telling the user which screen they are looking at and add additional screens 
> of other parts of the app beneath it on this page and a link at the bottom to 
> take the user back to the previous page, the home page.
>  
>  I like the "Latest News" item. Feels like a 'heartbeat' on the site. That's 
> good.
>  
>  Here's some additional food for though regarding content and structure.
>  
>  Have a look at panic.com or http://www.panic.com/transmit/ and check out how 
> they have loads of features on the product page. Consider having a "product 
> features" page with iconography and a quick description of each feature. This 
> is a nice way to pay off your central product 'value proposition' (Ex. 
> "Share, Chat, Browse. Anonymously. On the Free Network." - Then give a list 
> of features somewhere on the site that explains this in a bit more detail.)
>  
>  Here's a big structure idea. It looks like there are two main content areas: 
> Content related to the app: And, content related to the Freenet Project. In 
> the future, restructuring the site, and making a clear distinction between 
> these two types of content, could really help the overall UX and usability of 
> the site. This type of structure would also help a broader audience to 
> self-segment and get to their desired content more easily.
>  
>  Best,
> Brendan
> 
I have deployed the current website redesign, which is essentially Dieppe's 
work with much feedback from here. It is working, the only problem is the 
translation page is empty:
http://freenetproject.org/translation.html

Should we remove it for now?

IMHO the new site is an improvement over the old one, especially with the big 
download button. However I'm sure we could further improve it.
-- 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: 

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Monday 20 July 2009 17:08:50 bren...@artvote.com wrote:
 Hi All,
 Over the past couple months I've been speaking with Ian about your 
 fascinating project and recently, he's asked me to give feedback on the new 
 site design so I've included a previous email addressing that below. 
 Looking forward to more conversations with each of you!
 -Brendan
 p.s. Here's my brief bio: I am a digital product designer, interested in 
 interactive design, information architecture, user experience, business 
 strategy, and generally making life easier and more fun. 
 
 //
 
 Hi Ian,
  
  Overall, I think that this visual design is a nice step forward. The 
 navigation is clearer, and having a single column structure gives you room 
 for a left hand navigation down the road on lower-level pages, should you 
 need it.
  
  As far as color, do you have sense of what you want the brand colors to be? 
 It looks like the new release of the app, and the logo mark, are blue. 
 Perhaps consider having a blue-tone color theme rather that the black grey 
 theme. Having the header black makes it feel dark. I would be mindful of 
 the connotations that darkness has (good and bad). Might be interesting to 
 see a lighter treatment. Perhaps blue and grey of beige?
  
  (As far as information design and the presentation of the content on the 
 pages, see the comments below on structure and content. It makes sense to 
 address the larger questions prior to focusing the presentation of page-level 
 content.)
  
  That's pretty much my first blush on design.
  
  I think there are a couple quick-wins that are usability related, that I've 
 included below (12).
  
  PAGE: Home page:
  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
  
  1. Since you've opted to have the app installer automatically begin the 
 install after they click (instead of downloading first) Here are a few 
 preparatory steps you might want to include to prepare the suer.
  Make the label on the button more descriptive and consider adding a few 
 bullets above the button to describe the installation process. For instance:
  Getting started is easy! When you install, you'll do the following:
  
 · Download and automatically open the installer
 · Set your security preference and connection speed
 · Explore the feature through the Getting Started Tutorial
  [Install Freenet now = button label]
  
  2. Screenshots are great to have. Consider adding a trigger that says Click 
 to View Screenshots under the one on the right, and on the destination page, 
 add more screenshots and label what those screens are. Currently the 
 destination page is just a single larger screenshot. Add a description 
 telling the user which screen they are looking at and add additional screens 
 of other parts of the app beneath it on this page and a link at the bottom to 
 take the user back to the previous page, the home page.
  
  I like the Latest News item. Feels like a 'heartbeat' on the site. That's 
 good.
  
  Here's some additional food for though regarding content and structure.
  
  Have a look at panic.com or http://www.panic.com/transmit/ and check out how 
 they have loads of features on the product page. Consider having a product 
 features page with iconography and a quick description of each feature. This 
 is a nice way to pay off your central product 'value proposition' (Ex. 
 Share, Chat, Browse. Anonymously. On the Free Network. - Then give a list 
 of features somewhere on the site that explains this in a bit more detail.)
  
  Here's a big structure idea. It looks like there are two main content areas: 
 Content related to the app: And, content related to the Freenet Project. In 
 the future, restructuring the site, and making a clear distinction between 
 these two types of content, could really help the overall UX and usability of 
 the site. This type of structure would also help a broader audience to 
 self-segment and get to their desired content more easily.
  
  Best,
 Brendan
 
I have deployed the current website redesign, which is essentially Dieppe's 
work with much feedback from here. It is working, the only problem is the 
translation page is empty:
http://freenetproject.org/translation.html

Should we remove it for now?

IMHO the new site is an improvement over the old one, especially with the big 
download button. However I'm sure we could further improve it.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Zero3]

Matthew Toseland skrev:
 I have deployed the current website redesign, which is essentially Dieppe's 
 work with much feedback from here. It is working, the only problem is the 
 translation page is empty:
 http://freenetproject.org/translation.html
 
 Should we remove it for now?
 
 IMHO the new site is an improvement over the old one, especially with the big 
 download button. However I'm sure we could further improve it.

*claps*

I think it is a great improvement! (with room for optimization, as always)

The screenshot is still worse than awful though.

- Zero3
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Clément]

Le vendredi 31 juillet 2009 21:00:45, Matthew Toseland a écrit :
 On Monday 20 July 2009 17:08:50 bren...@artvote.com wrote:
  Hi All,
  Over the past couple months I've been speaking with Ian about your
  fascinating project and recently, he's asked me to give feedback on the
  new site design so I've included a previous email addressing that below.
  Looking forward to more conversations with each of you!
  -Brendan
  p.s. Here's my brief bio: I am a digital product designer, interested in
  interactive design, information architecture, user experience, business
  strategy, and generally making life easier and more fun.
 
  //
 
  Hi Ian,
 
   Overall, I think that this visual design is a nice step forward. The
  navigation is clearer, and having a single column structure gives you
  room for a left hand navigation down the road on lower-level pages,
  should you need it.
 
   As far as color, do you have sense of what you want the brand colors to
  be? It looks like the new release of the app, and the logo mark, are
  blue. Perhaps consider having a blue-tone color theme rather that the
  black grey theme. Having the header black makes it feel dark. I would
  be mindful of the connotations that darkness has (good and bad). Might
  be interesting to see a lighter treatment. Perhaps blue and grey of
  beige?
 
   (As far as information design and the presentation of the content on the
  pages, see the comments below on structure and content. It makes sense to
  address the larger questions prior to focusing the presentation of
  page-level content.)
 
   That's pretty much my first blush on design.
 
   I think there are a couple quick-wins that are usability related, that
  I've included below (12).
 
   PAGE: Home page:
   http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
 
   1. Since you've opted to have the app installer automatically begin the
  install after they click (instead of downloading first) Here are a few
  preparatory steps you might want to include to prepare the suer. Make the
  label on the button more descriptive and consider adding a few bullets
  above the button to describe the installation process. For instance:
  Getting started is easy! When you install, you'll do the following:
 
  · Download and automatically open the installer
  · Set your security preference and connection speed
  · Explore the feature through the Getting Started Tutorial
   [Install Freenet now = button label]
 
   2. Screenshots are great to have. Consider adding a trigger that says
  Click to View Screenshots under the one on the right, and on the
  destination page, add more screenshots and label what those screens are.
  Currently the destination page is just a single larger screenshot. Add a
  description telling the user which screen they are looking at and add
  additional screens of other parts of the app beneath it on this page and
  a link at the bottom to take the user back to the previous page, the home
  page.
 
   I like the Latest News item. Feels like a 'heartbeat' on the site.
  That's good.
 
   Here's some additional food for though regarding content and structure.
 
   Have a look at panic.com or http://www.panic.com/transmit/ and check out
  how they have loads of features on the product page. Consider having a
  product features page with iconography and a quick description of each
  feature. This is a nice way to pay off your central product 'value
  proposition' (Ex. Share, Chat, Browse. Anonymously. On the Free
  Network. - Then give a list of features somewhere on the site that
  explains this in a bit more detail.)
 
   Here's a big structure idea. It looks like there are two main content
  areas: Content related to the app: And, content related to the Freenet
  Project. In the future, restructuring the site, and making a clear
  distinction between these two types of content, could really help the
  overall UX and usability of the site. This type of structure would also
  help a broader audience to self-segment and get to their desired content
  more easily.
 
   Best,
  Brendan

 I have deployed the current website redesign, which is essentially Dieppe's
 work with much feedback from here. It is working, the only problem is the
 translation page is empty: http://freenetproject.org/translation.html

 Should we remove it for now?

Sure, I just wanted to put an howto for translators there, but well, I don't 
know the translation process. And I'm too busy right now to do it.
 IMHO the new site is an improvement over the old one, especially with the
 big download button. However I'm sure we could further improve it.
Well, there's room for improvment, yes. I can start to work on that after my 
internship, which ends the 18 september. I'll still have a report to do, so I 
think I'll work on that in the beginning of october ; of course, if anyone 
wants to improve it, don't hesitate. The most important thing to do being the 
screenshots, which should be quite 

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Wednesday 29 July 2009 03:52:26 you wrote:
> On Tue, Jul 28, 2009 at 4:55 PM, Matthew
> Toseland wrote:
> > AFAICS no. I'm not saying we should go with a static only host, I'm saying 
> > we shouldn't
> > make dynamic that which doesn't need to be, on grounds of CPU cost (which 
> > determines
> > responsiveness in practice). Modern systems (even apache 2 to a reasonable 
> > degree)
> > can serve static content ridiculously fast, that's not true of dynamic 
> > content.
> 
> Oh come on now, this argument is just as implausible.  Are you
> seriously claiming that there will be a consequential difference in
> speed (in terms of user experience) between a statically served page,
> and a page that is dynamically generated in response to a simple test
> of a HTTP header?
> 
> Research I've seen is that response time only has a measurable effect
> if its over 100ms, and only a perceptible slowness if its over 700ms.
> I can't believe that, unless we're running our web server on an Atari
> 800XL, that there will be any significant difference in response time
> just because the page is dynamically generated.

VMs can be very slow, in terms of time-slicing CPUs. And Google bills by CPU 
time. In both cases, for any sensible implementation, the CPU cost of sending a 
static web page which is frequently accessed is essentially nil, and the cost 
of running a script is considerably more than that. However, if it is 
implemented by a redirect in the apache config it is probably fast enough.

When we have had slashdots, we have often had performance issues even with a 
dedicated server (which is vastly more powerful than any VM or shared hosting 
service). Although these have been due to configured limits in apache, or 
possibly to logging to a database.
-- 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: 

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Wednesday 29 July 2009 03:52:26 you wrote:
 On Tue, Jul 28, 2009 at 4:55 PM, Matthew
 Toselandt...@amphibian.dyndns.org wrote:
  AFAICS no. I'm not saying we should go with a static only host, I'm saying 
  we shouldn't
  make dynamic that which doesn't need to be, on grounds of CPU cost (which 
  determines
  responsiveness in practice). Modern systems (even apache 2 to a reasonable 
  degree)
  can serve static content ridiculously fast, that's not true of dynamic 
  content.
 
 Oh come on now, this argument is just as implausible.  Are you
 seriously claiming that there will be a consequential difference in
 speed (in terms of user experience) between a statically served page,
 and a page that is dynamically generated in response to a simple test
 of a HTTP header?
 
 Research I've seen is that response time only has a measurable effect
 if its over 100ms, and only a perceptible slowness if its over 700ms.
 I can't believe that, unless we're running our web server on an Atari
 800XL, that there will be any significant difference in response time
 just because the page is dynamically generated.

VMs can be very slow, in terms of time-slicing CPUs. And Google bills by CPU 
time. In both cases, for any sensible implementation, the CPU cost of sending a 
static web page which is frequently accessed is essentially nil, and the cost 
of running a script is considerably more than that. However, if it is 
implemented by a redirect in the apache config it is probably fast enough.

When we have had slashdots, we have often had performance issues even with a 
dedicated server (which is vastly more powerful than any VM or shared hosting 
service). Although these have been due to configured limits in apache, or 
possibly to logging to a database.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Tuesday 28 July 2009 20:32:45 you wrote:
> On Tue, Jul 28, 2009 at 2:18 PM, Matthew
> Toseland wrote:
> >> To do what is proposed (change the download button/text depending on the
> >> user-agent/OS), you need redirects: not dynamic page generation.
> >>
> > Okay so there is a cheap solution as long as we have access to the server 
> > config. Great.
> 
> Where are you getting this idea that we're somehow going to save lots
> of $$$ by going with a static-only web host?  Is there even such a
> thing as a static-only web host in this day and age (except Freenet
> itself of course)?

AFAICS no. I'm not saying we should go with a static only host, I'm saying we 
shouldn't make dynamic that which doesn't need to be, on grounds of CPU cost 
(which determines responsiveness in practice). Modern systems (even apache 2 to 
a reasonable degree) can serve static content ridiculously fast, that's not 
true of dynamic content.
-- 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: 

[freenet-dev] Hello Freenet (& design feedback)

[Ian Clarke]

On Tue, Jul 28, 2009 at 4:55 PM, Matthew
Toseland wrote:
> AFAICS no. I'm not saying we should go with a static only host, I'm saying we 
> shouldn't
> make dynamic that which doesn't need to be, on grounds of CPU cost (which 
> determines
> responsiveness in practice). Modern systems (even apache 2 to a reasonable 
> degree)
> can serve static content ridiculously fast, that's not true of dynamic 
> content.

Oh come on now, this argument is just as implausible.  Are you
seriously claiming that there will be a consequential difference in
speed (in terms of user experience) between a statically served page,
and a page that is dynamically generated in response to a simple test
of a HTTP header?

Research I've seen is that response time only has a measurable effect
if its over 100ms, and only a perceptible slowness if its over 700ms.
I can't believe that, unless we're running our web server on an Atari
800XL, that there will be any significant difference in response time
just because the page is dynamically generated.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Monday 27 July 2009 18:42:11 Ian Clarke wrote:
> On Mon, Jul 27, 2009 at 6:27 AM, Matthew
> Toseland wrote:
> >> > I disagree, php or java reduces performance and increases costs, for all 
> >> > hosting options.
> >>
> >> Are you serious? ?I can imagine someone making that kind of argument
> >> against dynamic page generation in 1994, but not now.
> >
> > It happens to be true. On grounds of security, performance and cost. We get 
> > a lot of hits, and any cheap hosting option, including the Google app 
> > platform, will be much slower with .php's than with static HTML.
> 
> Well, firstly you can't use PHP on the Google App platform, it has to
> be Python or Java, and I suspect in either case it will be as fast as
> we could ever need it to be.
> 
> > And we don't want an expensive hosting option: we want to save money.
> 
> Crippling our website to save a few dollars per month (and that is, at
> most, all it would be) is extremely short-sighted.  Google App Engine
> is free up to a pretty high traffic volume AFAIK.  I think we'd
> probably have a hard time finding hosting that *didn't* support some
> form of dynamic page generation.
> 
> >> I don't like using Javascript for this, and I certainly don't like the
> >> assumption that we are no-longer permitted to do any dynamic page
> >> generation server side. ?That is crazy.
> >
> > We don't use it now. We haven't used it for years, all the php stuff is is 
> > SSIs, which
> > can be compiled in advance. But please step back a bit: we are talking 
> > about what
> > happens *when javascript is turned off*. Only paranoid geeks turn off 
> > javascript. If
> > they have to choose their OS then that's no great hardship for them.
> 
> Except that it appears to be unreliable even with Javascript turned
> on.  I experienced problems with it in Safari 4 (with Javascript most
> assuredly switched on).

Right, so we need to determine whether we can reliably detect the operating 
system in the 3 major browsers using javascript only. If we can't then clearly 
we need to do it on the server. Acceptable?
...
On Tuesday 28 July 2009 19:59:43 Florent Daigni?re wrote:
> * Ian Clarke  [2009-07-27 12:42:11]:
> > Crippling our website to save a few dollars per month (and that is, at
> > most, all it would be) is extremely short-sighted.  Google App Engine
> > is free up to a pretty high traffic volume AFAIK.  I think we'd
> > probably have a hard time finding hosting that *didn't* support some
> > form of dynamic page generation.
> > 
> 
> Hmmm, Freenet?
> 
> To do what is proposed (change the download button/text depending on the
> user-agent/OS), you need redirects: not dynamic page generation.
> 
Okay so there is a cheap solution as long as we have access to the server 
config. Great.
-- 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: 

[freenet-dev] Hello Freenet (& design feedback)

[Florent Daignière]

* Ian Clarke  [2009-07-27 12:42:11]:

> On Mon, Jul 27, 2009 at 6:27 AM, Matthew
> Toseland wrote:
> >> > I disagree, php or java reduces performance and increases costs, for all 
> >> > hosting options.
> >>
> >> Are you serious? ?I can imagine someone making that kind of argument
> >> against dynamic page generation in 1994, but not now.
> >
> > It happens to be true. On grounds of security, performance and cost. We get 
> > a lot of hits, and any cheap hosting option, including the Google app 
> > platform, will be much slower with .php's than with static HTML.
> 
> Well, firstly you can't use PHP on the Google App platform, it has to
> be Python or Java, and I suspect in either case it will be as fast as
> we could ever need it to be.
> 
> > And we don't want an expensive hosting option: we want to save money.
> 
> Crippling our website to save a few dollars per month (and that is, at
> most, all it would be) is extremely short-sighted.  Google App Engine
> is free up to a pretty high traffic volume AFAIK.  I think we'd
> probably have a hard time finding hosting that *didn't* support some
> form of dynamic page generation.
> 

Hmmm, Freenet?

To do what is proposed (change the download button/text depending on the
user-agent/OS), you need redirects: not dynamic page generation.

But agreed, that can be done with dynamic page generation too.

That being said, it would be nice if fproxy was able to handle such
redirections through a special key type for instance.

> >> I don't like using Javascript for this, and I certainly don't like the
> >> assumption that we are no-longer permitted to do any dynamic page
> >> generation server side. ?That is crazy.
> >
> > We don't use it now. We haven't used it for years, all the php stuff is is 
> > SSIs, which
> > can be compiled in advance. But please step back a bit: we are talking 
> > about what
> > happens *when javascript is turned off*. Only paranoid geeks turn off 
> > javascript. If
> > they have to choose their OS then that's no great hardship for them.
> 
> Except that it appears to be unreliable even with Javascript turned
> on.  I experienced problems with it in Safari 4 (with Javascript most
> assuredly switched on).
> 

That's presumably because you're one of the few using a mac and reading
 this mailing list :/

It can probably be fixed.

> > Of course it is true that all plausible hosting options support php, but 
> > just because
> > they support it doesn't mean that there is any good reason to use it on the 
> > homepage.
> 
> There is a reason that practically every website on the Internet uses
> server-side page generation (PHP or otherwise).
> 
> Declaring that our entire website must be static is an arbitrary,
> pointless, and very limiting restriction.
> 
> I'm not aware of a single other website anywhere that has opted to
> limit itself to static page generation, either on the grounds of
> security or cost.  This is because its a crazy argument.
> 

Agreed.

NextGen$
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: 

[freenet-dev] Hello Freenet (& design feedback)

[Ian Clarke]

On Tue, Jul 28, 2009 at 2:18 PM, Matthew
Toseland wrote:
>> To do what is proposed (change the download button/text depending on the
>> user-agent/OS), you need redirects: not dynamic page generation.
>>
> Okay so there is a cheap solution as long as we have access to the server 
> config. Great.

Where are you getting this idea that we're somehow going to save lots
of $$$ by going with a static-only web host?  Is there even such a
thing as a static-only web host in this day and age (except Freenet
itself of course)?

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674

Re: [freenet-dev] Hello Freenet ( design feedback)

[Florent Daignière]

* Ian Clarke i...@locut.us [2009-07-27 12:42:11]:

 On Mon, Jul 27, 2009 at 6:27 AM, Matthew
 Toselandt...@amphibian.dyndns.org wrote:
   I disagree, php or java reduces performance and increases costs, for all 
   hosting options.
 
  Are you serious?  I can imagine someone making that kind of argument
  against dynamic page generation in 1994, but not now.
 
  It happens to be true. On grounds of security, performance and cost. We get 
  a lot of hits, and any cheap hosting option, including the Google app 
  platform, will be much slower with .php's than with static HTML.
 
 Well, firstly you can't use PHP on the Google App platform, it has to
 be Python or Java, and I suspect in either case it will be as fast as
 we could ever need it to be.
 
  And we don't want an expensive hosting option: we want to save money.
 
 Crippling our website to save a few dollars per month (and that is, at
 most, all it would be) is extremely short-sighted.  Google App Engine
 is free up to a pretty high traffic volume AFAIK.  I think we'd
 probably have a hard time finding hosting that *didn't* support some
 form of dynamic page generation.
 

Hmmm, Freenet?

To do what is proposed (change the download button/text depending on the
user-agent/OS), you need redirects: not dynamic page generation.

But agreed, that can be done with dynamic page generation too.

That being said, it would be nice if fproxy was able to handle such
redirections through a special key type for instance.

  I don't like using Javascript for this, and I certainly don't like the
  assumption that we are no-longer permitted to do any dynamic page
  generation server side.  That is crazy.
 
  We don't use it now. We haven't used it for years, all the php stuff is is 
  SSIs, which
  can be compiled in advance. But please step back a bit: we are talking 
  about what
  happens *when javascript is turned off*. Only paranoid geeks turn off 
  javascript. If
  they have to choose their OS then that's no great hardship for them.
 
 Except that it appears to be unreliable even with Javascript turned
 on.  I experienced problems with it in Safari 4 (with Javascript most
 assuredly switched on).
 

That's presumably because you're one of the few using a mac and reading
 this mailing list :/

It can probably be fixed.

  Of course it is true that all plausible hosting options support php, but 
  just because
  they support it doesn't mean that there is any good reason to use it on the 
  homepage.
 
 There is a reason that practically every website on the Internet uses
 server-side page generation (PHP or otherwise).
 
 Declaring that our entire website must be static is an arbitrary,
 pointless, and very limiting restriction.
 
 I'm not aware of a single other website anywhere that has opted to
 limit itself to static page generation, either on the grounds of
 security or cost.  This is because its a crazy argument.
 

Agreed.

NextGen$


signature.asc
Description: Digital signature
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Monday 27 July 2009 18:42:11 Ian Clarke wrote:
 On Mon, Jul 27, 2009 at 6:27 AM, Matthew
 Toselandt...@amphibian.dyndns.org wrote:
   I disagree, php or java reduces performance and increases costs, for all 
   hosting options.
 
  Are you serious?  I can imagine someone making that kind of argument
  against dynamic page generation in 1994, but not now.
 
  It happens to be true. On grounds of security, performance and cost. We get 
  a lot of hits, and any cheap hosting option, including the Google app 
  platform, will be much slower with .php's than with static HTML.
 
 Well, firstly you can't use PHP on the Google App platform, it has to
 be Python or Java, and I suspect in either case it will be as fast as
 we could ever need it to be.
 
  And we don't want an expensive hosting option: we want to save money.
 
 Crippling our website to save a few dollars per month (and that is, at
 most, all it would be) is extremely short-sighted.  Google App Engine
 is free up to a pretty high traffic volume AFAIK.  I think we'd
 probably have a hard time finding hosting that *didn't* support some
 form of dynamic page generation.
 
  I don't like using Javascript for this, and I certainly don't like the
  assumption that we are no-longer permitted to do any dynamic page
  generation server side.  That is crazy.
 
  We don't use it now. We haven't used it for years, all the php stuff is is 
  SSIs, which
  can be compiled in advance. But please step back a bit: we are talking 
  about what
  happens *when javascript is turned off*. Only paranoid geeks turn off 
  javascript. If
  they have to choose their OS then that's no great hardship for them.
 
 Except that it appears to be unreliable even with Javascript turned
 on.  I experienced problems with it in Safari 4 (with Javascript most
 assuredly switched on).

Right, so we need to determine whether we can reliably detect the operating 
system in the 3 major browsers using javascript only. If we can't then clearly 
we need to do it on the server. Acceptable?
...
On Tuesday 28 July 2009 19:59:43 Florent Daignière wrote:
 * Ian Clarke i...@locut.us [2009-07-27 12:42:11]:
  Crippling our website to save a few dollars per month (and that is, at
  most, all it would be) is extremely short-sighted.  Google App Engine
  is free up to a pretty high traffic volume AFAIK.  I think we'd
  probably have a hard time finding hosting that *didn't* support some
  form of dynamic page generation.
  
 
 Hmmm, Freenet?
 
 To do what is proposed (change the download button/text depending on the
 user-agent/OS), you need redirects: not dynamic page generation.
 
Okay so there is a cheap solution as long as we have access to the server 
config. Great.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Tuesday 28 July 2009 20:32:45 you wrote:
 On Tue, Jul 28, 2009 at 2:18 PM, Matthew
 Toselandt...@amphibian.dyndns.org wrote:
  To do what is proposed (change the download button/text depending on the
  user-agent/OS), you need redirects: not dynamic page generation.
 
  Okay so there is a cheap solution as long as we have access to the server 
  config. Great.
 
 Where are you getting this idea that we're somehow going to save lots
 of $$$ by going with a static-only web host?  Is there even such a
 thing as a static-only web host in this day and age (except Freenet
 itself of course)?

AFAICS no. I'm not saying we should go with a static only host, I'm saying we 
shouldn't make dynamic that which doesn't need to be, on grounds of CPU cost 
(which determines responsiveness in practice). Modern systems (even apache 2 to 
a reasonable degree) can serve static content ridiculously fast, that's not 
true of dynamic content.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Ian Clarke]

On Tue, Jul 28, 2009 at 4:55 PM, Matthew
Toselandt...@amphibian.dyndns.org wrote:
 AFAICS no. I'm not saying we should go with a static only host, I'm saying we 
 shouldn't
 make dynamic that which doesn't need to be, on grounds of CPU cost (which 
 determines
 responsiveness in practice). Modern systems (even apache 2 to a reasonable 
 degree)
 can serve static content ridiculously fast, that's not true of dynamic 
 content.

Oh come on now, this argument is just as implausible.  Are you
seriously claiming that there will be a consequential difference in
speed (in terms of user experience) between a statically served page,
and a page that is dynamically generated in response to a simple test
of a HTTP header?

Research I've seen is that response time only has a measurable effect
if its over 100ms, and only a perceptible slowness if its over 700ms.
I can't believe that, unless we're running our web server on an Atari
800XL, that there will be any significant difference in response time
just because the page is dynamically generated.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Monday 27 July 2009 16:13:15 brendan at artvote.com wrote:
> 
>  Well, we did have a whole page concerning downloading Freenet, but Clement 
> decided it's better to have a download link on the homepage, much as 
> getfirefox.com does...
> 
> <--
> It's a good idea to have both a download page, as well as a link off the 
> homepage, which I believe you will have, right? 
> -->
> B

Glad you agree! Getfirefox doesn't show much in the way of instructions, but 
Freenet is more conceptually unfamiliar, so maybe we do need some minimal 
installation instructions on the homepage? Would we have space?
-- 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: 

[freenet-dev] Hello Freenet (& design feedback)

[Ian Clarke]

On Mon, Jul 27, 2009 at 6:27 AM, Matthew
Toseland wrote:
>> > I disagree, php or java reduces performance and increases costs, for all 
>> > hosting options.
>>
>> Are you serious? ?I can imagine someone making that kind of argument
>> against dynamic page generation in 1994, but not now.
>
> It happens to be true. On grounds of security, performance and cost. We get a 
> lot of hits, and any cheap hosting option, including the Google app platform, 
> will be much slower with .php's than with static HTML.

Well, firstly you can't use PHP on the Google App platform, it has to
be Python or Java, and I suspect in either case it will be as fast as
we could ever need it to be.

> And we don't want an expensive hosting option: we want to save money.

Crippling our website to save a few dollars per month (and that is, at
most, all it would be) is extremely short-sighted.  Google App Engine
is free up to a pretty high traffic volume AFAIK.  I think we'd
probably have a hard time finding hosting that *didn't* support some
form of dynamic page generation.

>> I don't like using Javascript for this, and I certainly don't like the
>> assumption that we are no-longer permitted to do any dynamic page
>> generation server side. ?That is crazy.
>
> We don't use it now. We haven't used it for years, all the php stuff is is 
> SSIs, which
> can be compiled in advance. But please step back a bit: we are talking about 
> what
> happens *when javascript is turned off*. Only paranoid geeks turn off 
> javascript. If
> they have to choose their OS then that's no great hardship for them.

Except that it appears to be unreliable even with Javascript turned
on.  I experienced problems with it in Safari 4 (with Javascript most
assuredly switched on).

> Of course it is true that all plausible hosting options support php, but just 
> because
> they support it doesn't mean that there is any good reason to use it on the 
> homepage.

There is a reason that practically every website on the Internet uses
server-side page generation (PHP or otherwise).

Declaring that our entire website must be static is an arbitrary,
pointless, and very limiting restriction.

I'm not aware of a single other website anywhere that has opted to
limit itself to static page generation, either on the grounds of
security or cost.  This is because its a crazy argument.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Monday 20 July 2009 17:08:50 brendan at artvote.com wrote:
> Hi All,
> Over the past couple months I've been speaking with Ian about your 
> fascinating project and recently, he's asked me to give feedback on the new 
> site design so I've included a previous email addressing that below. 
> Looking forward to more conversations with each of you!
> -Brendan
> p.s. Here's my brief bio: I am a digital product designer, interested in 
> interactive design, information architecture, user experience, business 
> strategy, and generally making life easier and more fun. 
> 
> //
> 
> Hi Ian,
>  
>  Overall, I think that this visual design is a nice step forward. The 
> navigation is clearer, and having a single column structure gives you room 
> for a left hand navigation down the road on lower-level pages, should you 
> need it.

We probably need it on the documentation page - that makes 3 layers, menu -> 
dropdown submenu -> doc submenu.
>  
>  As far as color, do you have sense of what you want the brand colors to be? 
> It looks like the new release of the app, and the logo mark, are blue. 
> Perhaps consider having a blue-tone color theme rather that the black grey 
> theme. Having the header black makes it feel "dark". I would be mindful of 
> the connotations that "darkness" has (good and bad). Might be interesting to 
> see a lighter treatment. Perhaps blue and grey of beige?

Many of its connotations may be good for us. But we need to consider all 
possible users, so probably other colors are better.
>  
>  (As far as information design and the presentation of the content on the 
> pages, see the comments below on structure and content. It makes sense to 
> address the larger questions prior to focusing the presentation of page-level 
> content.)
>  
>  That's pretty much my first blush on design.
>  
>  I think there are a couple quick-wins that are usability related, that I've 
> included below (1&2).
>  
>  PAGE: Home page:
>  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
>  
>  1. Since you've opted to have the app installer automatically begin the 
> install after they click (instead of downloading first) Here are a few 
> preparatory steps you might want to include to prepare the suer.
>  Make the label on the button more descriptive and consider adding a few 
> bullets above the button to describe the installation process. For instance:
>  "Getting started is easy! When you install, you'll do the following:
>  
> ? Download and automatically open the installer
> ? Set your security preference and connection speed
> ? Explore the feature through the Getting Started Tutorial"
>  ["Install Freenet now" = button label]

Well, we did have a whole page concerning downloading Freenet, but Clement 
decided it's better to have a download link on the homepage, much as 
getfirefox.com does...
>  
>  2. Screenshots are great to have. Consider adding a trigger that says "Click 
> to View Screenshots" under the one on the right, and on the destination page, 
> add more screenshots and label what those screens are. Currently the 
> destination page is just a single larger screenshot. Add a description 
> telling the user which screen they are looking at and add additional screens 
> of other parts of the app beneath it on this page and a link at the bottom to 
> take the user back to the previous page, the home page.

Agreed we need more and better screenshots.
>  
>  I like the "Latest News" item. Feels like a 'heartbeat' on the site. That's 
> good.
>  
>  Here's some additional food for though regarding content and structure.
>  
>  Have a look at panic.com or http://www.panic.com/transmit/ and check out how 
> they have loads of features on the product page. Consider having a "product 
> features" page with iconography and a quick description of each feature. This 
> is a nice way to pay off your central product 'value proposition' (Ex. 
> "Share, Chat, Browse. Anonymously. On the Free Network." - Then give a list 
> of features somewhere on the site that explains this in a bit more detail.)

This loosely corresponds to "What is Freenet?", no? We should have a separate 
page with lots of bullet points, maybe linked from it? Or get rid of "What is 
Freenet?"? I guess it is possible to explain the core functionality in bullet 
points ...
>  
>  Here's a big structure idea. It looks like there are two main content areas: 
> Content related to the app: And, content related to the Freenet Project. In 
> the future, restructuring the site, and making a clear distinction between 
> these two types of content, could really help the overall UX and usability of 
> the site. This type of structure would also help a broader audience to 
> self-segment and get to their desired content more easily.

Hmmm, perhaps, not sure I have anything to say on this.
>  
>  Best,
> Brendan
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: 

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Monday 27 July 2009 04:18:50 Ian Clarke wrote:
> On Sat, Jul 25, 2009 at 2:40 PM, Matthew
> Toseland wrote:
> >> In fact, we do detect their platform, but we use javascript. So there are 
> >> two
> >> issues here :
> >> the user disabled the javascript (we should use server-side identification,
> >> ian's right),
> >
> > I disagree, php or java reduces performance and increases costs, for all 
> > hosting options.
> 
> Are you serious?  I can imagine someone making that kind of argument
> against dynamic page generation in 1994, but not now.

It happens to be true. On grounds of security, performance and cost. We get a 
lot of hits, and any cheap hosting option, including the Google app platform, 
will be much slower with .php's than with static HTML. And we don't want an 
expensive hosting option: we want to save money.
> 
> There is no way that we are going to migrate our website to a hosting
> option that does not support some form of dynamic page generation,
> that would be total insanity.  Brendan is right, this should be done
> server-side, and we'd be totally handicapping ourselves if we don't
> have the ability for server-side dynamic page generation.  I'm having
> a hard time believing its even necessary to debate this.
> 
> > We will still need javascript for it to work smoothly. But if javascript is 
> > turned off, we can just
> > display all of them - it doesn't have to look good.
> 
> I don't like using Javascript for this, and I certainly don't like the
> assumption that we are no-longer permitted to do any dynamic page
> generation server side.  That is crazy.

We don't use it now. We haven't used it for years, all the php stuff is is 
SSIs, which can be compiled in advance. But please step back a bit: we are 
talking about what happens *when javascript is turned off*. Only paranoid geeks 
turn off javascript. If they have to choose their OS then that's no great 
hardship for them.

Of course it is true that all plausible hosting options support php, but just 
because they support it doesn't mean that there is any good reason to use it on 
the homepage.
> 
> Ian.
-- 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: 

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Monday 27 July 2009 04:18:50 Ian Clarke wrote:
 On Sat, Jul 25, 2009 at 2:40 PM, Matthew
 Toselandt...@amphibian.dyndns.org wrote:
  In fact, we do detect their platform, but we use javascript. So there are 
  two
  issues here :
  the user disabled the javascript (we should use server-side identification,
  ian's right),
 
  I disagree, php or java reduces performance and increases costs, for all 
  hosting options.
 
 Are you serious?  I can imagine someone making that kind of argument
 against dynamic page generation in 1994, but not now.

It happens to be true. On grounds of security, performance and cost. We get a 
lot of hits, and any cheap hosting option, including the Google app platform, 
will be much slower with .php's than with static HTML. And we don't want an 
expensive hosting option: we want to save money.
 
 There is no way that we are going to migrate our website to a hosting
 option that does not support some form of dynamic page generation,
 that would be total insanity.  Brendan is right, this should be done
 server-side, and we'd be totally handicapping ourselves if we don't
 have the ability for server-side dynamic page generation.  I'm having
 a hard time believing its even necessary to debate this.
 
  We will still need javascript for it to work smoothly. But if javascript is 
  turned off, we can just
  display all of them - it doesn't have to look good.
 
 I don't like using Javascript for this, and I certainly don't like the
 assumption that we are no-longer permitted to do any dynamic page
 generation server side.  That is crazy.

We don't use it now. We haven't used it for years, all the php stuff is is 
SSIs, which can be compiled in advance. But please step back a bit: we are 
talking about what happens *when javascript is turned off*. Only paranoid geeks 
turn off javascript. If they have to choose their OS then that's no great 
hardship for them.

Of course it is true that all plausible hosting options support php, but just 
because they support it doesn't mean that there is any good reason to use it on 
the homepage.
 
 Ian.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Monday 20 July 2009 17:08:50 bren...@artvote.com wrote:
 Hi All,
 Over the past couple months I've been speaking with Ian about your 
 fascinating project and recently, he's asked me to give feedback on the new 
 site design so I've included a previous email addressing that below. 
 Looking forward to more conversations with each of you!
 -Brendan
 p.s. Here's my brief bio: I am a digital product designer, interested in 
 interactive design, information architecture, user experience, business 
 strategy, and generally making life easier and more fun. 
 
 //
 
 Hi Ian,
  
  Overall, I think that this visual design is a nice step forward. The 
 navigation is clearer, and having a single column structure gives you room 
 for a left hand navigation down the road on lower-level pages, should you 
 need it.

We probably need it on the documentation page - that makes 3 layers, menu - 
dropdown submenu - doc submenu.
  
  As far as color, do you have sense of what you want the brand colors to be? 
 It looks like the new release of the app, and the logo mark, are blue. 
 Perhaps consider having a blue-tone color theme rather that the black grey 
 theme. Having the header black makes it feel dark. I would be mindful of 
 the connotations that darkness has (good and bad). Might be interesting to 
 see a lighter treatment. Perhaps blue and grey of beige?

Many of its connotations may be good for us. But we need to consider all 
possible users, so probably other colors are better.
  
  (As far as information design and the presentation of the content on the 
 pages, see the comments below on structure and content. It makes sense to 
 address the larger questions prior to focusing the presentation of page-level 
 content.)
  
  That's pretty much my first blush on design.
  
  I think there are a couple quick-wins that are usability related, that I've 
 included below (12).
  
  PAGE: Home page:
  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
  
  1. Since you've opted to have the app installer automatically begin the 
 install after they click (instead of downloading first) Here are a few 
 preparatory steps you might want to include to prepare the suer.
  Make the label on the button more descriptive and consider adding a few 
 bullets above the button to describe the installation process. For instance:
  Getting started is easy! When you install, you'll do the following:
  
 · Download and automatically open the installer
 · Set your security preference and connection speed
 · Explore the feature through the Getting Started Tutorial
  [Install Freenet now = button label]

Well, we did have a whole page concerning downloading Freenet, but Clement 
decided it's better to have a download link on the homepage, much as 
getfirefox.com does...
  
  2. Screenshots are great to have. Consider adding a trigger that says Click 
 to View Screenshots under the one on the right, and on the destination page, 
 add more screenshots and label what those screens are. Currently the 
 destination page is just a single larger screenshot. Add a description 
 telling the user which screen they are looking at and add additional screens 
 of other parts of the app beneath it on this page and a link at the bottom to 
 take the user back to the previous page, the home page.

Agreed we need more and better screenshots.
  
  I like the Latest News item. Feels like a 'heartbeat' on the site. That's 
 good.
  
  Here's some additional food for though regarding content and structure.
  
  Have a look at panic.com or http://www.panic.com/transmit/ and check out how 
 they have loads of features on the product page. Consider having a product 
 features page with iconography and a quick description of each feature. This 
 is a nice way to pay off your central product 'value proposition' (Ex. 
 Share, Chat, Browse. Anonymously. On the Free Network. - Then give a list 
 of features somewhere on the site that explains this in a bit more detail.)

This loosely corresponds to What is Freenet?, no? We should have a separate 
page with lots of bullet points, maybe linked from it? Or get rid of What is 
Freenet?? I guess it is possible to explain the core functionality in bullet 
points ...
  
  Here's a big structure idea. It looks like there are two main content areas: 
 Content related to the app: And, content related to the Freenet Project. In 
 the future, restructuring the site, and making a clear distinction between 
 these two types of content, could really help the overall UX and usability of 
 the site. This type of structure would also help a broader audience to 
 self-segment and get to their desired content more easily.

Hmmm, perhaps, not sure I have anything to say on this.
  
  Best,
 Brendan


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[brendan]

Well, we did have a whole page concerning downloading Freenet, but Clement decided it's better to have a download link on the homepage, much as getfirefox.com does...--It's a good idea to have both a download page, as well as a link off the homepage, which I believe you will have, right? --B



___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Ian Clarke]

On Mon, Jul 27, 2009 at 6:27 AM, Matthew
Toselandt...@amphibian.dyndns.org wrote:
  I disagree, php or java reduces performance and increases costs, for all 
  hosting options.

 Are you serious?  I can imagine someone making that kind of argument
 against dynamic page generation in 1994, but not now.

 It happens to be true. On grounds of security, performance and cost. We get a 
 lot of hits, and any cheap hosting option, including the Google app platform, 
 will be much slower with .php's than with static HTML.

Well, firstly you can't use PHP on the Google App platform, it has to
be Python or Java, and I suspect in either case it will be as fast as
we could ever need it to be.

 And we don't want an expensive hosting option: we want to save money.

Crippling our website to save a few dollars per month (and that is, at
most, all it would be) is extremely short-sighted.  Google App Engine
is free up to a pretty high traffic volume AFAIK.  I think we'd
probably have a hard time finding hosting that *didn't* support some
form of dynamic page generation.

 I don't like using Javascript for this, and I certainly don't like the
 assumption that we are no-longer permitted to do any dynamic page
 generation server side.  That is crazy.

 We don't use it now. We haven't used it for years, all the php stuff is is 
 SSIs, which
 can be compiled in advance. But please step back a bit: we are talking about 
 what
 happens *when javascript is turned off*. Only paranoid geeks turn off 
 javascript. If
 they have to choose their OS then that's no great hardship for them.

Except that it appears to be unreliable even with Javascript turned
on.  I experienced problems with it in Safari 4 (with Javascript most
assuredly switched on).

 Of course it is true that all plausible hosting options support php, but just 
 because
 they support it doesn't mean that there is any good reason to use it on the 
 homepage.

There is a reason that practically every website on the Internet uses
server-side page generation (PHP or otherwise).

Declaring that our entire website must be static is an arbitrary,
pointless, and very limiting restriction.

I'm not aware of a single other website anywhere that has opted to
limit itself to static page generation, either on the grounds of
security or cost.  This is because its a crazy argument.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Monday 27 July 2009 16:13:15 bren...@artvote.com wrote:
 
  Well, we did have a whole page concerning downloading Freenet, but Clement 
 decided it's better to have a download link on the homepage, much as 
 getfirefox.com does...
 
 --
 It's a good idea to have both a download page, as well as a link off the 
 homepage, which I believe you will have, right? 
 --
 B

Glad you agree! Getfirefox doesn't show much in the way of instructions, but 
Freenet is more conceptually unfamiliar, so maybe we do need some minimal 
installation instructions on the homepage? Would we have space?


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello Freenet (& design feedback)

[Ian Clarke]

On Sat, Jul 25, 2009 at 2:40 PM, Matthew
Toseland wrote:
>> In fact, we do detect their platform, but we use javascript. So there are two
>> issues here :
>> the user disabled the javascript (we should use server-side identification,
>> ian's right),
>
> I disagree, php or java reduces performance and increases costs, for all 
> hosting options.

Are you serious?  I can imagine someone making that kind of argument
against dynamic page generation in 1994, but not now.

There is no way that we are going to migrate our website to a hosting
option that does not support some form of dynamic page generation,
that would be total insanity.  Brendan is right, this should be done
server-side, and we'd be totally handicapping ourselves if we don't
have the ability for server-side dynamic page generation.  I'm having
a hard time believing its even necessary to debate this.

> We will still need javascript for it to work smoothly. But if javascript is 
> turned off, we can just
> display all of them - it doesn't have to look good.

I don't like using Javascript for this, and I certainly don't like the
assumption that we are no-longer permitted to do any dynamic page
generation server side.  That is crazy.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674

Re: [freenet-dev] Hello Freenet ( design feedback)

[Ian Clarke]

On Sat, Jul 25, 2009 at 2:40 PM, Matthew
Toselandt...@amphibian.dyndns.org wrote:
 In fact, we do detect their platform, but we use javascript. So there are two
 issues here :
 the user disabled the javascript (we should use server-side identification,
 ian's right),

 I disagree, php or java reduces performance and increases costs, for all 
 hosting options.

Are you serious?  I can imagine someone making that kind of argument
against dynamic page generation in 1994, but not now.

There is no way that we are going to migrate our website to a hosting
option that does not support some form of dynamic page generation,
that would be total insanity.  Brendan is right, this should be done
server-side, and we'd be totally handicapping ourselves if we don't
have the ability for server-side dynamic page generation.  I'm having
a hard time believing its even necessary to debate this.

 We will still need javascript for it to work smoothly. But if javascript is 
 turned off, we can just
 display all of them - it doesn't have to look good.

I don't like using Javascript for this, and I certainly don't like the
assumption that we are no-longer permitted to do any dynamic page
generation server side.  That is crazy.

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello Freenet (& design feedback)

[Matthew Toseland]

On Wednesday 22 July 2009 16:03:38 Cl?ment wrote:
> Le mercredi 22 juillet 2009 16:45:43, brendan at artvote.com a ?crit :
> [...]
> >  > (As far as information design and the presentation of the content on the
> >  > pages, see the comments below on structure and content. It makes sense
> >  > to address the larger questions prior to focusing the presentation of
> >  > page-level content.)
> >  >
> >  > That's pretty much my first blush on design.
> >  >
> >  > I think there are a couple quick-wins that are usability related, that
> >  > I've included below (1&2).
> >  >
> >  > PAGE: Home page:
> >  > http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
> >  >
> >  > 1. Since you've opted to have the app installer automatically begin the
> >  > install after they click (instead of downloading first) Here are a few
> >  > preparatory steps you might want to include to prepare the suer. Make
> >  > the label on the button more descriptive and consider adding a few
> >  > bullets above the button to describe the installation process. For
> >  > instance: "Getting started is easy! When you install, you'll do the
> >  > following:
> >  >
> >  > ? Download and automatically open the installer
> >  > ? Set your security preference and connection speed
> >  > ? Explore the feature through the Getting Started Tutorial"
> >  > ["Install Freenet now" = button label]
> >
> >  Hum, that's a good idea, but I can see a problem : we use javascript to
> > detect the OS, and display only the right button. But, if javascript is
> > turned off, or the browser doesn't send the name of the OS it's running on,
> > we show all three buttons.
> >  So, if we add the little paragraph above, with no js, it will looks like
> > this
> >
> >  [Win button]
> >  [Paragraph above]
> >  [MacOS button]
> >  [Linux/unix button]
> >
> >  And I'm not sure it would be clear for the user.
> >
> >  <--
> >  Can we auto-detect their platform and just serve them the appropriate
> > button (and content) for that platform? (we can include a link to a
> > separate download page where they can download for other platforms - "Click
> > here to download the app for other operating systems"). I think the main
> > idea is to make it as simple as possible for them to download it for their
> > platform off the homepage AND to let them know what will happen whne they
> > initiate the download/install process. How does that sound?
> >  -Brendan
> >  -->
> >
> In fact, we do detect their platform, but we use javascript. So there are two 
> issues here :
> the user disabled the javascript (we should use server-side identification, 
> ian's right),

I disagree, php or java reduces performance and increases costs, for all 
hosting options. If the user turned javascript off then they can expect it to 
be ugly, we should make it minimally work in that case but we don't need it to 
be perfect.

> the user doesn't send the information we need.
> In both case, right now, we show all the buttons.
> The problem is that javawebstart is not used for windows, and if we show all 
> the buttons, we need to show the little description above. But if we do that, 
> it might be very confusing for windows users.

The problem is JWS has to be used on Mac, but it's also the best option for 
Linux - but only if it works. On Windows we have to show the exe, on mac we 
have to show the JWS, but on linux either javascript shows that JWS works, and 
we show the JWS button, and it works, or javascript says it works and then it 
doesn't and the user needs to click on a button to show more details, or it's 
not detected and we have to show the more details anyway. The more details 
being open a command line and type two lines...

> So, if we use server side identification, we reduce this to one case. But we 
> have to think of it, don't we ?

We will still need javascript for it to work smoothly. But if javascript is 
turned off, we can just display all of them - it doesn't have to look good.
-- 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: 

Re: [freenet-dev] Hello Freenet ( design feedback)

[Matthew Toseland]

On Wednesday 22 July 2009 16:03:38 Clément wrote:
 Le mercredi 22 juillet 2009 16:45:43, bren...@artvote.com a écrit :
 [...]
(As far as information design and the presentation of the content on the
pages, see the comments below on structure and content. It makes sense
to address the larger questions prior to focusing the presentation of
page-level content.)
   
That's pretty much my first blush on design.
   
I think there are a couple quick-wins that are usability related, that
I've included below (12).
   
PAGE: Home page:
http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
   
1. Since you've opted to have the app installer automatically begin the
install after they click (instead of downloading first) Here are a few
preparatory steps you might want to include to prepare the suer. Make
the label on the button more descriptive and consider adding a few
bullets above the button to describe the installation process. For
instance: Getting started is easy! When you install, you'll do the
following:
   
? Download and automatically open the installer
? Set your security preference and connection speed
? Explore the feature through the Getting Started Tutorial
[Install Freenet now = button label]
 
   Hum, that's a good idea, but I can see a problem : we use javascript to
  detect the OS, and display only the right button. But, if javascript is
  turned off, or the browser doesn't send the name of the OS it's running on,
  we show all three buttons.
   So, if we add the little paragraph above, with no js, it will looks like
  this
 
   [Win button]
   [Paragraph above]
   [MacOS button]
   [Linux/unix button]
 
   And I'm not sure it would be clear for the user.
 
   --
   Can we auto-detect their platform and just serve them the appropriate
  button (and content) for that platform? (we can include a link to a
  separate download page where they can download for other platforms - Click
  here to download the app for other operating systems). I think the main
  idea is to make it as simple as possible for them to download it for their
  platform off the homepage AND to let them know what will happen whne they
  initiate the download/install process. How does that sound?
   -Brendan
   --
 
 In fact, we do detect their platform, but we use javascript. So there are two 
 issues here :
 the user disabled the javascript (we should use server-side identification, 
 ian's right),

I disagree, php or java reduces performance and increases costs, for all 
hosting options. If the user turned javascript off then they can expect it to 
be ugly, we should make it minimally work in that case but we don't need it to 
be perfect.

 the user doesn't send the information we need.
 In both case, right now, we show all the buttons.
 The problem is that javawebstart is not used for windows, and if we show all 
 the buttons, we need to show the little description above. But if we do that, 
 it might be very confusing for windows users.

The problem is JWS has to be used on Mac, but it's also the best option for 
Linux - but only if it works. On Windows we have to show the exe, on mac we 
have to show the JWS, but on linux either javascript shows that JWS works, and 
we show the JWS button, and it works, or javascript says it works and then it 
doesn't and the user needs to click on a button to show more details, or it's 
not detected and we have to show the more details anyway. The more details 
being open a command line and type two lines...

 So, if we use server side identification, we reduce this to one case. But we 
 have to think of it, don't we ?

We will still need javascript for it to work smoothly. But if javascript is 
turned off, we can just display all of them - it doesn't have to look good.


signature.asc
Description: This is a digitally signed message part.
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[freenet-dev] Hello Freenet (& design feedback)

[Clément]

Le mercredi 22 juillet 2009 16:45:43, brendan at artvote.com a ?crit :
[...]
>  > (As far as information design and the presentation of the content on the
>  > pages, see the comments below on structure and content. It makes sense
>  > to address the larger questions prior to focusing the presentation of
>  > page-level content.)
>  >
>  > That's pretty much my first blush on design.
>  >
>  > I think there are a couple quick-wins that are usability related, that
>  > I've included below (1&2).
>  >
>  > PAGE: Home page:
>  > http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
>  >
>  > 1. Since you've opted to have the app installer automatically begin the
>  > install after they click (instead of downloading first) Here are a few
>  > preparatory steps you might want to include to prepare the suer. Make
>  > the label on the button more descriptive and consider adding a few
>  > bullets above the button to describe the installation process. For
>  > instance: "Getting started is easy! When you install, you'll do the
>  > following:
>  >
>  > ? Download and automatically open the installer
>  > ? Set your security preference and connection speed
>  > ? Explore the feature through the Getting Started Tutorial"
>  > ["Install Freenet now" = button label]
>
>  Hum, that's a good idea, but I can see a problem : we use javascript to
> detect the OS, and display only the right button. But, if javascript is
> turned off, or the browser doesn't send the name of the OS it's running on,
> we show all three buttons.
>  So, if we add the little paragraph above, with no js, it will looks like
> this
>
>  [Win button]
>  [Paragraph above]
>  [MacOS button]
>  [Linux/unix button]
>
>  And I'm not sure it would be clear for the user.
>
>  <--
>  Can we auto-detect their platform and just serve them the appropriate
> button (and content) for that platform? (we can include a link to a
> separate download page where they can download for other platforms - "Click
> here to download the app for other operating systems"). I think the main
> idea is to make it as simple as possible for them to download it for their
> platform off the homepage AND to let them know what will happen whne they
> initiate the download/install process. How does that sound?
>  -Brendan
>  -->
>
In fact, we do detect their platform, but we use javascript. So there are two 
issues here :
the user disabled the javascript (we should use server-side identification, 
ian's right),
the user doesn't send the information we need.
In both case, right now, we show all the buttons.
The problem is that javawebstart is not used for windows, and if we show all 
the buttons, we need to show the little description above. But if we do that, 
it might be very confusing for windows users.
So, if we use server side identification, we reduce this to one case. But we 
have to think of it, don't we ?
>  > 2. Screenshots are great to have. Consider adding a trigger that says
>  > "Click to View Screenshots" under the one on the right, and on the
>  > destination page, add more screenshots and label what those screens are.
>  > Currently the destination page is just a single larger screenshot. Add a
>  > description telling the user which screen they are looking at and add
>  > additional screens of other parts of the app beneath it on this page and
>  > a link at the bottom to take the user back to the previous page, the
>  > home page.
>
>  Yeah, screenshot suck right now. To tell the truth, I didn't focused on
> it, since we don't have any good looking screenshot, and I was waiting for
> it. Plus, we don't know what to do :
>  one screenshot, as it is now, reduced (which looks ugly), linking to the
>  screenshots page ?
>  several screenshots focused on features, like
>  http://www.mozilla-europe.org/en/firefox/ ?
>  I'd vote for the second one (but it needs more screenshots...).
>
>  > I like the "Latest News" item. Feels like a 'heartbeat' on the site.
>  > That's good.
>
>  Cool :)
>
>  > Here's some additional food for though regarding content and structure.
>  >
>  > Have a look at panic.com or http://www.panic.com/transmit/ and check out
>  > how they have loads of features on the product page. Consider having a
>  > "product features" page with iconography and a quick description of each
>  > feature. This is a nice way to pay off your central product 'value
>  > proposition' (Ex. "Share, Chat, Browse. Anonymously. On the Free
>  > Network." - Then give a list of features somewhere on the site that
>  > explains this in a bit more detail.)
>
>  Good idea.
>
>  > Here's a big structure idea. It looks like there are two main content
>  > areas: Content related to the app: And, content related to the Freenet
>  > Project. In the future, restructuring the site, and making a clear
>  > distinction between these two types of content, could really help the
>  > overall UX and usability of the site. This type of structure would also
>  > help a broader audience 

[freenet-dev] Hello Freenet (& design feedback)

[bren...@artvote.com]

An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Hello Freenet ( design feedback)

[brendan]

 Original Message 
Subject: Devl Digest, Vol 46, Issue 39
From: devl-requ...@freenetproject.org
Date: Tue, July 21, 2009 3:46 pm
To: devl@freenetproject.org

Send Devl mailing list submissions to
	devl@freenetproject.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
or, via email, send a message with subject or body 'help' to
	devl-requ...@freenetproject.org

You can reach the person managing the list at
	devl-ow...@freenetproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Devl digest..."


Today's Topics:

   1. Re: Hello Freenet ( design feedback) (Ian Clarke)
   2. Re: Hello Freenet ( design feedback) (Cl?ment)
   3. Re: Installer file name (bren...@artvote.com)
   4. Re: Installer file name (Ian Clarke)
   5. Re: Installer file name (Zero3)


--

Message: 1
Date: Tue, 21 Jul 2009 08:40:56 -0500
From: Ian Clarke i...@locut.us
Subject: Re: [freenet-dev] Hello Freenet ( design feedback)
To: Discussion of development issues devl@freenetproject.org
Message-ID:
	823242bd0907210640s3749b0e3l37e4158bf4866...@mail.gmail.com
Content-Type: text/plain; charset="iso-8859-1"

Hey Brendan,
Thanks for sending this, I can't tell you how valuable it is to get a fresh
perspective on this stuff from an expert.

 As far as color, do you have sense of what you want the brand colors to be?
 It looks like the new release of the app, and the logo mark, are blue.
 Perhaps consider having a blue-tone color theme rather that the black grey
 theme. Having the header black makes it feel "dark". I would be mindful of
 the connotations that "darkness" has (good and bad). Might be interesting to
 see a lighter treatment. Perhaps blue and grey of beige?


Yes, its a tough one - I agree that it would be valuable to see a few
options.  We went for a white "open" feel with the current website, and
there are advantages to this to combat the sense that anonymity is something
negative.


 2. Screenshots are great to have. Consider adding a trigger that says
 "Click to View Screenshots" under the one on the right, and on the
 destination page, add more screenshots and label what those screens are.
 Currently the destination page is just a single larger screenshot. Add a
 description telling the user which screen they are looking at and add
 additional screens of other parts of the app beneath it on this page and a
 link at the bottom to take the user back to the previous page, the home
 page.


Yes, we definitely need a better screenshot.  Problem is that the current
Freenet UI isn't all that photogenic :-)
  
--
I think that's okay. The screenshots here can reveal functionality by
showing different areas of the app. I think the aesthetics are
secondary to giving the visitor an understanding of what the app is and
what it allows you to do. I'd keep that in mind when selecting the screenshots.
-Brendan
--

I agree with pretty-much all your other points.  Clement, can you comment on
this?

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
-- next part --
An HTML attachment was scrubbed...
URL: http://emu.freenetproject.org/pipermail/devl/attachments/20090721/2eba14c2/attachment.htm 

--

Message: 2
Date: Tue, 21 Jul 2009 16:33:44 +0200
From: Cl?ment cvol...@gmail.com
Subject: Re: [freenet-dev] Hello Freenet ( design feedback)
To: Discussion of development issues devl@freenetproject.org
Message-ID: 200907211633.44710.cvol...@gmail.com
Content-Type: Text/Plain;  charset="utf-8"

Le lundi 20 juillet 2009 18:08:50, bren...@artvote.com a ?crit :
 Hi All,
 Over the past couple months I've been speaking with Ian about your
 fascinating project and recently, he's asked me to give feedback on the new
 site design so I've included a previous email addressing that below.
 Looking forward to more conversations with each of you!
 -Brendan
 p.s. Here's my brief bio: I am a digital product designer, interested in
 interactive design, information architecture, user experience, business
 strategy, and generally making life easier and more fun.

 //

 Hi Ian,

  Overall, I think that this visual design is a nice step forward. The
 navigation is clearer, and having a single column structure gives you room
 for a left hand navigation down the road on lower-level pages, should you
 need it.

  As far as color, do you have sense of what you want the brand colors to
 be? It looks like the new release of the app, and the logo mark, are blue.
 Perhaps consider having a blue-tone color theme rather that the black grey
 theme. Having the header black makes it feel "dark". I would be mindful of
 the connotations that "darkness" has (good and bad). Migh

Re: [freenet-dev] Hello Freenet ( design feedback)

[Clément]

Le mercredi 22 juillet 2009 16:45:43, bren...@artvote.com a écrit :
[...]
   (As far as information design and the presentation of the content on the
   pages, see the comments below on structure and content. It makes sense
   to address the larger questions prior to focusing the presentation of
   page-level content.)
  
   That's pretty much my first blush on design.
  
   I think there are a couple quick-wins that are usability related, that
   I've included below (12).
  
   PAGE: Home page:
   http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
  
   1. Since you've opted to have the app installer automatically begin the
   install after they click (instead of downloading first) Here are a few
   preparatory steps you might want to include to prepare the suer. Make
   the label on the button more descriptive and consider adding a few
   bullets above the button to describe the installation process. For
   instance: Getting started is easy! When you install, you'll do the
   following:
  
   ? Download and automatically open the installer
   ? Set your security preference and connection speed
   ? Explore the feature through the Getting Started Tutorial
   [Install Freenet now = button label]

  Hum, that's a good idea, but I can see a problem : we use javascript to
 detect the OS, and display only the right button. But, if javascript is
 turned off, or the browser doesn't send the name of the OS it's running on,
 we show all three buttons.
  So, if we add the little paragraph above, with no js, it will looks like
 this

  [Win button]
  [Paragraph above]
  [MacOS button]
  [Linux/unix button]

  And I'm not sure it would be clear for the user.

  --
  Can we auto-detect their platform and just serve them the appropriate
 button (and content) for that platform? (we can include a link to a
 separate download page where they can download for other platforms - Click
 here to download the app for other operating systems). I think the main
 idea is to make it as simple as possible for them to download it for their
 platform off the homepage AND to let them know what will happen whne they
 initiate the download/install process. How does that sound?
  -Brendan
  --

In fact, we do detect their platform, but we use javascript. So there are two 
issues here :
the user disabled the javascript (we should use server-side identification, 
ian's right),
the user doesn't send the information we need.
In both case, right now, we show all the buttons.
The problem is that javawebstart is not used for windows, and if we show all 
the buttons, we need to show the little description above. But if we do that, 
it might be very confusing for windows users.
So, if we use server side identification, we reduce this to one case. But we 
have to think of it, don't we ?
   2. Screenshots are great to have. Consider adding a trigger that says
   Click to View Screenshots under the one on the right, and on the
   destination page, add more screenshots and label what those screens are.
   Currently the destination page is just a single larger screenshot. Add a
   description telling the user which screen they are looking at and add
   additional screens of other parts of the app beneath it on this page and
   a link at the bottom to take the user back to the previous page, the
   home page.

  Yeah, screenshot suck right now. To tell the truth, I didn't focused on
 it, since we don't have any good looking screenshot, and I was waiting for
 it. Plus, we don't know what to do :
  one screenshot, as it is now, reduced (which looks ugly), linking to the
  screenshots page ?
  several screenshots focused on features, like
  http://www.mozilla-europe.org/en/firefox/ ?
  I'd vote for the second one (but it needs more screenshots...).

   I like the Latest News item. Feels like a 'heartbeat' on the site.
   That's good.

  Cool :)

   Here's some additional food for though regarding content and structure.
  
   Have a look at panic.com or http://www.panic.com/transmit/ and check out
   how they have loads of features on the product page. Consider having a
   product features page with iconography and a quick description of each
   feature. This is a nice way to pay off your central product 'value
   proposition' (Ex. Share, Chat, Browse. Anonymously. On the Free
   Network. - Then give a list of features somewhere on the site that
   explains this in a bit more detail.)

  Good idea.

   Here's a big structure idea. It looks like there are two main content
   areas: Content related to the app: And, content related to the Freenet
   Project. In the future, restructuring the site, and making a clear
   distinction between these two types of content, could really help the
   overall UX and usability of the site. This type of structure would also
   help a broader audience to self-segment and get to their desired content
   more easily.

  Well, I'd like more input on this if it's possible, because that's what I
  wanted to do, but 

[freenet-dev] Hello Freenet (& design feedback)

[Clément]

Le lundi 20 juillet 2009 18:08:50, brendan at artvote.com a ?crit :
> Hi All,
> Over the past couple months I've been speaking with Ian about your
> fascinating project and recently, he's asked me to give feedback on the new
> site design so I've included a previous email addressing that below.
> Looking forward to more conversations with each of you!
> -Brendan
> p.s. Here's my brief bio: I am a digital product designer, interested in
> interactive design, information architecture, user experience, business
> strategy, and generally making life easier and more fun.
>
> //
>
> Hi Ian,
>
>  Overall, I think that this visual design is a nice step forward. The
> navigation is clearer, and having a single column structure gives you room
> for a left hand navigation down the road on lower-level pages, should you
> need it.
>
>  As far as color, do you have sense of what you want the brand colors to
> be? It looks like the new release of the app, and the logo mark, are blue.
> Perhaps consider having a blue-tone color theme rather that the black grey
> theme. Having the header black makes it feel "dark". I would be mindful of
> the connotations that "darkness" has (good and bad). Might be interesting
> to see a lighter treatment. Perhaps blue and grey of beige?
>
That's true that we (I and my girlfriend) didn't think of that when we choosed 
the colors. We took black and gray color because it generally looks clean, and 
it help making a contrast with the reading zone (which is white here). But I 
agree those colors don't mean anything. 
With the current site, I choosed a blue gradient (which looks old) to white, 
because it give a feeling of "freedom" (sky, ...).
Anyway, all that to say : I'll try with the colors you mentioned :)
>  (As far as information design and the presentation of the content on the
> pages, see the comments below on structure and content. It makes sense to
> address the larger questions prior to focusing the presentation of
> page-level content.)
>
>  That's pretty much my first blush on design.
>
>  I think there are a couple quick-wins that are usability related, that
> I've included below (1&2).
>
>  PAGE: Home page:
>  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html
>
>  1. Since you've opted to have the app installer automatically begin the
> install after they click (instead of downloading first) Here are a few
> preparatory steps you might want to include to prepare the suer. Make the
> label on the button more descriptive and consider adding a few bullets
> above the button to describe the installation process. For instance:
> "Getting started is easy! When you install, you'll do the following:
>
> ? Download and automatically open the installer
> ? Set your security preference and connection speed
> ? Explore the feature through the Getting Started Tutorial"
>  ["Install Freenet now" = button label]
>
Hum, that's a good idea, but I can see a problem : we use javascript to detect 
the OS, and display only the right button. But, if javascript is turned off, or 
the browser doesn't send the name of the OS it's running on, we show all three 
buttons.
So, if we add the little paragraph above, with no js, it will looks like this 
:
[Win button]
[Paragraph above]
[MacOS button]
[Linux/unix button]

And I'm not sure it would be clear for the user. 
>  2. Screenshots are great to have. Consider adding a trigger that says
> "Click to View Screenshots" under the one on the right, and on the
> destination page, add more screenshots and label what those screens are.
> Currently the destination page is just a single larger screenshot. Add a
> description telling the user which screen they are looking at and add
> additional screens of other parts of the app beneath it on this page and a
> link at the bottom to take the user back to the previous page, the home
> page.
>
Yeah, screenshot suck right now. To tell the truth, I didn't focused on it, 
since we don't have any good looking screenshot, and I was waiting for it.
Plus, we don't know what to do :
one screenshot, as it is now, reduced (which looks ugly), linking to the 
screenshots page ?
several screenshots focused on features, like 
http://www.mozilla-europe.org/en/firefox/ ?
I'd vote for the second one (but it needs more screenshots...).
>  I like the "Latest News" item. Feels like a 'heartbeat' on the site.
> That's good.
>
Cool :)
>  Here's some additional food for though regarding content and structure.
>
>  Have a look at panic.com or http://www.panic.com/transmit/ and check out
> how they have loads of features on the product page. Consider having a
> "product features" page with iconography and a quick description of each
> feature. This is a nice way to pay off your central product 'value
> proposition' (Ex. "Share, Chat, Browse. Anonymously. On the Free Network."
> - Then give a list of features somewhere on the site that explains this in
> a bit more detail.)
>
Good idea.
>  Here's a big structure 

[freenet-dev] Hello Freenet (& design feedback)

[Ian Clarke]

Hey Brendan,
Thanks for sending this, I can't tell you how valuable it is to get a fresh
perspective on this stuff from an expert.

 As far as color, do you have sense of what you want the brand colors to be?
> It looks like the new release of the app, and the logo mark, are blue.
> Perhaps consider having a blue-tone color theme rather that the black grey
> theme. Having the header black makes it feel "dark". I would be mindful of
> the connotations that "darkness" has (good and bad). Might be interesting to
> see a lighter treatment. Perhaps blue and grey of beige?
>

Yes, its a tough one - I agree that it would be valuable to see a few
options.  We went for a white "open" feel with the current website, and
there are advantages to this to combat the sense that anonymity is something
negative.


> 2. Screenshots are great to have. Consider adding a trigger that says
> "Click to View Screenshots" under the one on the right, and on the
> destination page, add more screenshots and label what those screens are.
> Currently the destination page is just a single larger screenshot. Add a
> description telling the user which screen they are looking at and add
> additional screens of other parts of the app beneath it on this page and a
> link at the bottom to take the user back to the previous page, the home
> page.
>

Yes, we definitely need a better screenshot.  Problem is that the current
Freenet UI isn't all that photogenic :-)

I agree with pretty-much all your other points.  Clement, can you comment on
this?

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: ian at uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
-- next part --
An HTML attachment was scrubbed...
URL: 

Re: [freenet-dev] Hello Freenet ( design feedback)

[Ian Clarke]

Hey Brendan,
Thanks for sending this, I can't tell you how valuable it is to get a fresh
perspective on this stuff from an expert.

 As far as color, do you have sense of what you want the brand colors to be?
 It looks like the new release of the app, and the logo mark, are blue.
 Perhaps consider having a blue-tone color theme rather that the black grey
 theme. Having the header black makes it feel dark. I would be mindful of
 the connotations that darkness has (good and bad). Might be interesting to
 see a lighter treatment. Perhaps blue and grey of beige?


Yes, its a tough one - I agree that it would be valuable to see a few
options.  We went for a white open feel with the current website, and
there are advantages to this to combat the sense that anonymity is something
negative.


 2. Screenshots are great to have. Consider adding a trigger that says
 Click to View Screenshots under the one on the right, and on the
 destination page, add more screenshots and label what those screens are.
 Currently the destination page is just a single larger screenshot. Add a
 description telling the user which screen they are looking at and add
 additional screens of other parts of the app beneath it on this page and a
 link at the bottom to take the user back to the previous page, the home
 page.


Yes, we definitely need a better screenshot.  Problem is that the current
Freenet UI isn't all that photogenic :-)

I agree with pretty-much all your other points.  Clement, can you comment on
this?

Ian.

-- 
Ian Clarke
CEO, Uprizer Labs
Email: i...@uprizer.com
Ph: +1 512 422 3588
Fax: +1 512 276 6674
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Re: [freenet-dev] Hello Freenet ( design feedback)

[Clément]

Le lundi 20 juillet 2009 18:08:50, bren...@artvote.com a écrit :
 Hi All,
 Over the past couple months I've been speaking with Ian about your
 fascinating project and recently, he's asked me to give feedback on the new
 site design so I've included a previous email addressing that below.
 Looking forward to more conversations with each of you!
 -Brendan
 p.s. Here's my brief bio: I am a digital product designer, interested in
 interactive design, information architecture, user experience, business
 strategy, and generally making life easier and more fun.

 //

 Hi Ian,

  Overall, I think that this visual design is a nice step forward. The
 navigation is clearer, and having a single column structure gives you room
 for a left hand navigation down the road on lower-level pages, should you
 need it.

  As far as color, do you have sense of what you want the brand colors to
 be? It looks like the new release of the app, and the logo mark, are blue.
 Perhaps consider having a blue-tone color theme rather that the black grey
 theme. Having the header black makes it feel dark. I would be mindful of
 the connotations that darkness has (good and bad). Might be interesting
 to see a lighter treatment. Perhaps blue and grey of beige?

That's true that we (I and my girlfriend) didn't think of that when we choosed 
the colors. We took black and gray color because it generally looks clean, and 
it help making a contrast with the reading zone (which is white here). But I 
agree those colors don't mean anything. 
With the current site, I choosed a blue gradient (which looks old) to white, 
because it give a feeling of freedom (sky, ...).
Anyway, all that to say : I'll try with the colors you mentioned :)
  (As far as information design and the presentation of the content on the
 pages, see the comments below on structure and content. It makes sense to
 address the larger questions prior to focusing the presentation of
 page-level content.)

  That's pretty much my first blush on design.

  I think there are a couple quick-wins that are usability related, that
 I've included below (12).

  PAGE: Home page:
  http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html

  1. Since you've opted to have the app installer automatically begin the
 install after they click (instead of downloading first) Here are a few
 preparatory steps you might want to include to prepare the suer. Make the
 label on the button more descriptive and consider adding a few bullets
 above the button to describe the installation process. For instance:
 Getting started is easy! When you install, you'll do the following:

 · Download and automatically open the installer
 · Set your security preference and connection speed
 · Explore the feature through the Getting Started Tutorial
  [Install Freenet now = button label]

Hum, that's a good idea, but I can see a problem : we use javascript to detect 
the OS, and display only the right button. But, if javascript is turned off, or 
the browser doesn't send the name of the OS it's running on, we show all three 
buttons.
So, if we add the little paragraph above, with no js, it will looks like this 
:
[Win button]
[Paragraph above]
[MacOS button]
[Linux/unix button]

And I'm not sure it would be clear for the user. 
  2. Screenshots are great to have. Consider adding a trigger that says
 Click to View Screenshots under the one on the right, and on the
 destination page, add more screenshots and label what those screens are.
 Currently the destination page is just a single larger screenshot. Add a
 description telling the user which screen they are looking at and add
 additional screens of other parts of the app beneath it on this page and a
 link at the bottom to take the user back to the previous page, the home
 page.

Yeah, screenshot suck right now. To tell the truth, I didn't focused on it, 
since we don't have any good looking screenshot, and I was waiting for it.
Plus, we don't know what to do :
one screenshot, as it is now, reduced (which looks ugly), linking to the 
screenshots page ?
several screenshots focused on features, like 
http://www.mozilla-europe.org/en/firefox/ ?
I'd vote for the second one (but it needs more screenshots...).
  I like the Latest News item. Feels like a 'heartbeat' on the site.
 That's good.

Cool :)
  Here's some additional food for though regarding content and structure.

  Have a look at panic.com or http://www.panic.com/transmit/ and check out
 how they have loads of features on the product page. Consider having a
 product features page with iconography and a quick description of each
 feature. This is a nice way to pay off your central product 'value
 proposition' (Ex. Share, Chat, Browse. Anonymously. On the Free Network.
 - Then give a list of features somewhere on the site that explains this in
 a bit more detail.)

Good idea.
  Here's a big structure idea. It looks like there are two main content
 areas: Content related to the app: And, content 

[freenet-dev] Hello Freenet (& design feedback)

[bren...@artvote.com]

An HTML attachment was scrubbed...
URL: 

[freenet-dev] Hello Freenet ( design feedback)

[brendan]

Hi All,Over the past couple months I've been speaking with Ian about your fascinating project and recently, he's asked me to give feedback on the new site design so I've included a previous email addressing that below. Looking forward to more conversations with each of you!-Brendanp.s. Here's my brief bio: I am a digital product designer, interested in interactive design,
information architecture, user experience, business strategy, and
generally making life easier and more fun. //Hi Ian,  Overall, I think that this visual design is a nice
step forward. The navigation is clearer, and having a single column
structure gives you room for a left hand navigation down the road on
lower-level pages, should you need it.  As far as color, do you
have sense of what you want the brand colors to be? It looks like the
new release of the app, and the logo mark, are blue. Perhaps consider
having a blue-tone color theme rather that the black grey theme. Having
the header black makes it feel "dark". I would be mindful of the
connotations that "darkness" has (good and bad). Might be interesting
to see a lighter treatment. Perhaps blue and grey of beige? 
(As far as information design and the presentation of the content on
the pages, see the comments below on structure and content. It makes
sense to address the larger questions prior to focusing the
presentation of page-level content.)  That's pretty much my first blush on design.  I think there are a couple quick-wins that are usability related, that I've included below (12).  PAGE: Home page: http://amphibian.dyndns.org.nyud.net/freenet/newsite/index.html 
1. Since you've opted to have the app installer automatically begin the
install after they click (instead of downloading first) Here are a few
preparatory steps you might want to include to prepare the suer.
Make the label on the button more descriptive and consider adding a few
bullets above the button to describe the installation process. For
instance: "Getting started is easy! When you install, you'll do the following: · Download and automatically open the installer · Set your security preference and connection speed · Explore the feature through the Getting Started Tutorial" ["Install Freenet now" = button label] 
2. Screenshots are great to have. Consider adding a trigger that says
"Click to View Screenshots" under the one on the right, and on the
destination page, add more screenshots and label what those screens
are. Currently the destination page is just a single larger screenshot.
Add a description telling the user which screen they are looking at and
add additional screens of other parts of the app beneath it on this
page and a link at the bottom to take the user back to the previous
page, the home page.  I like the "Latest News" item. Feels like a 'heartbeat' on the site. That's good.  Here's some additional food for though regarding content and structure.  Have a look at panic.com or http://www.panic.com/transmit/
and check out how they have loads of features on the product page.
Consider having a "product features" page with iconography and a quick
description of each feature. This is a nice way to pay off your central
product 'value proposition' (Ex. "Share, Chat, Browse. Anonymously. On
the Free Network." - Then give a list of features somewhere on the site
that explains this in a bit more detail.)  Here's a big
structure idea. It looks like there are two main content areas: Content
related to the app: And, content related to the Freenet Project. In the
future, restructuring the site, and making a clear distinction between
these two types of content, could really help the overall UX and
usability of the site. This type of structure would also help a broader
audience to self-segment and get to their desired content more easily. 
Best,Brendan 
___
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

[Freenet-dev] Hello, all!

[Stephen Blackheath]

Hello, everyone.

I'd like to join your development team, if I might.  I have very strong
Java and cryptography experience, and I am very keen on this project.  My
experience includes the working on the JDK for IBM back in 1997, and an
Internet Banking application for a bank.

I'm also full of ideas.  The only problem is, I don't have huge amounts of
time, but there you are.

Would anyone care to assign me a small job to start with?


Steve



___
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

[Freenet-dev] Hello, all!

[Brandon]

> Would anyone care to assign me a small job to start with?

Read and understand the documentation and source. That's a good start. :-)



___
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

[Freenet-dev] Hello

[The Xtremist]

Hello,
Im a C,Perl programmer with experience in
Sockets,Encryption,Unix(BSD,Linux). I am interested in doing a C Port
of Freenet...Therefore interested people(or people who are already
doing it)...please reply

Thanks


THE XTREMIST



___
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev

[Freenet-dev] hello.. its me fumiko

[fumiko kito]

dear friend.

hi doing? hope that every thing in going great with
you.
first. i wanna thank you for the nice progran(
freenet) as i heard. 

i am a girl  from japan. i really need freenet in my
coumuter. i downlaoded it from the internet, but i
couldn't undrstand anything. i mean there was just 
files and i have no idea how its work. i have nothing
about java... please help me. no no please dont  say i
have time or do it by your self. please 10 pleases
help me.  do it for me. i mean but the files and the
cood togather and send it.. i mean i wanna just
downlaod it as a program ( ready )  please . i will be
waiting for your reply... have a nice time

__
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

___
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev