Hi!
We already have a first set of technical requirements regarding software producing Tor website:
* It should generate static web pages, ready to be mirrored by our network of more than 70 mirrors. * The content must be kept in a version control system. The website was kept in Subversion, but it should probably be migrated to Git. * It needs to support the “Don't Repeat Yourself” principle for the content, e.g. the latest version of the Tor Browser Bundle needs to be kept at a single place but used at different places in the website. * It needs to support translations. A changes in a single paragraph should be easily to propagate to translators and to then to translations.
Hope that clears any further misunderstandings.
When you say static pages.. does that include static assets.. like building this with a JS framework (angular, backbone, etc)? Or no external assets, all in page?
On Tue, Jan 7, 2014 at 11:41 AM, Lunar lunar@torproject.org wrote:
Hi!
We already have a first set of technical requirements regarding software producing Tor website:
- It should generate static web pages, ready to be mirrored by our network of more than 70 mirrors.
- The content must be kept in a version control system. The website was kept in Subversion, but it should probably be migrated to Git.
- It needs to support the “Don't Repeat Yourself” principle for the content, e.g. the latest version of the Tor Browser Bundle needs to be kept at a single place but used at different places in the website.
- It needs to support translations. A changes in a single paragraph should be easily to propagate to translators and to then to translations.
Hope that clears any further misunderstandings.
-- Lunar lunar@torproject.org
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Drupal would handle the requirements but I have a feeling many other solutions would also... One thing to keep in mind is that static generation is quite trivial to implement in CMSs that don't support it out of the box.
On Tue, Jan 7, 2014 at 12:41 PM, Lunar lunar@torproject.org wrote:
Hi!
We already have a first set of technical requirements regarding software producing Tor website:
- It should generate static web pages, ready to be mirrored by our network of more than 70 mirrors.
- The content must be kept in a version control system. The website was kept in Subversion, but it should probably be migrated to Git.
- It needs to support the “Don't Repeat Yourself” principle for the content, e.g. the latest version of the Tor Browser Bundle needs to be kept at a single place but used at different places in the website.
- It needs to support translations. A changes in a single paragraph should be easily to propagate to translators and to then to translations.
Hope that clears any further misunderstandings.
-- Lunar lunar@torproject.org
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
On Tue, Jan 07, 2014 at 06:41:02PM +0100, lunar@torproject.org wrote 2.5K bytes in 0 lines about: : * It should generate static web pages, ready to be mirrored by our : network of more than 70 mirrors.
The site also needs to work offline as well. This means self-contained and zero 3rd party requests. We don't want to host dynamic sites. We have 5 webservers capable of serving static content, nothing more.
: * The content must be kept in a version control system. The website : was kept in Subversion, but it should probably be migrated to Git.
Maybe open to darcs, hg, fossil, etc. I think we want a distributed version control system, not just any old VCS.
Hi. I'm Sean. I'm an experienced full stack developer. Mostly rails, sinatra, php, drupal, mysql, jquery, backbone, angular, etc. I can also do devops stuff. I would love to help wherever I can. +1 for git. Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue? Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
On Jan 7, 2014, at 5:22 PM, andrew@torproject.is wrote:
On Tue, Jan 07, 2014 at 06:41:02PM +0100, lunar@torproject.org wrote 2.5K bytes in 0 lines about: : * It should generate static web pages, ready to be mirrored by our : network of more than 70 mirrors.
The site also needs to work offline as well. This means self-contained and zero 3rd party requests. We don't want to host dynamic sites. We have 5 webservers capable of serving static content, nothing more.
: * The content must be kept in a version control system. The website : was kept in Subversion, but it should probably be migrated to Git.
Maybe open to darcs, hg, fossil, etc. I think we want a distributed version control system, not just any old VCS.
-- Andrew http://tpo.is/contact pgp 0x6B4D6475 ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar <lunar@torproject.org (mailto:lunar@torproject.org)> wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar <lunar@torproject.org (mailto:lunar@torproject.org)> ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
I agree. Local files are much more secure than a local web server. Less attack profile for the computer starting TBB from USB for example.
Also less chance that something will fail (eg server fails to start).
Silviu. On Jan 8, 2014 10:12 AM, "Rey Dhuny" rey@spcshp.com wrote:
Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be used
because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things El ene 8, 2014 10:00 a.m., "Silviu Riley" silviu.riley@gmail.com escribió:
I agree. Local files are much more secure than a local web server. Less attack profile for the computer starting TBB from USB for example.
Also less chance that something will fail (eg server fails to start).
Silviu. On Jan 8, 2014 10:12 AM, "Rey Dhuny" rey@spcshp.com wrote:
Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be used
because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
I think this a nice idea on paper however in terms of an MVP (Minimal Viable Product) I think it would make sense, in my opinion, to aim for one release with graceful degradation.
We could then focus our efforts efficiently then after release we can look at different _release flavours_, so to speak.
Just my 2p :)
Rey
-- reyhan.org
On 8 Jan 2014, at 19:51, ramiro tinoco rowend@rowend.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
El ene 8, 2014 10:00 a.m., "Silviu Riley" silviu.riley@gmail.com escribió:
I agree. Local files are much more secure than a local web server. Less attack profile for the computer starting TBB from USB for example.
Also less chance that something will fail (eg server fails to start).
Silviu.
On Jan 8, 2014 10:12 AM, "Rey Dhuny" rey@spcshp.com wrote: Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
I think this a nice idea on paper however in terms of an MVP (Minimal Viable Product) I think it would make sense, in my opinion, to aim for one release with graceful degradation.
+1 on this. Let’s do this right, and let the pages degrade gracefully w/o javascript.
On Jan 8, 2014, at 9:04 PM, Rey Dhuny rey@spcshp.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
I think this a nice idea on paper however in terms of an MVP (Minimal Viable Product) I think it would make sense, in my opinion, to aim for one release with graceful degradation.
We could then focus our efforts efficiently then after release we can look at different _release flavours_, so to speak.
Just my 2p :)
Rey
-- reyhan.org
On 8 Jan 2014, at 19:51, ramiro tinoco rowend@rowend.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
El ene 8, 2014 10:00 a.m., "Silviu Riley" silviu.riley@gmail.com escribió: I agree. Local files are much more secure than a local web server. Less attack profile for the computer starting TBB from USB for example.
Also less chance that something will fail (eg server fails to start).
Silviu.
On Jan 8, 2014 10:12 AM, "Rey Dhuny" rey@spcshp.com wrote: Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
I agree. One project, with different target formats generated from the same markdown content. Whether we output HTML5 + JS, PDF or ePub is only a question of the presentation and should probably not be split into different projects.
Now for who is concerned with the best presentation for each format, this might be two or more different groups of people. Though I do not recommend splitting into formal teams, lest we start losing sight of our common goals.
Am 08.01.2014 um 21:04 schrieb Rey Dhuny rey@spcshp.com:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
I think this a nice idea on paper however in terms of an MVP (Minimal Viable Product) I think it would make sense, in my opinion, to aim for one release with graceful degradation.
We could then focus our efforts efficiently then after release we can look at different _release flavours_, so to speak.
Just my 2p :)
Rey
-- reyhan.org
On 8 Jan 2014, at 19:51, ramiro tinoco rowend@rowend.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
El ene 8, 2014 10:00 a.m., "Silviu Riley" silviu.riley@gmail.com escribió: I agree. Local files are much more secure than a local web server. Less attack profile for the computer starting TBB from USB for example.
Also less chance that something will fail (eg server fails to start).
Silviu.
On Jan 8, 2014 10:12 AM, "Rey Dhuny" rey@spcshp.com wrote: Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
* on the Wed, Jan 08, 2014 at 09:10:34PM +0100, Moritz S?? wrote:
I agree. One project, with different target formats generated from the same markdown content. Whether we output HTML5 + JS, PDF or ePub is only a question of the presentation and should probably not be split into different projects.
This project reminds me a lot of the way the Exim project does things.
http://www.exim.org/ is completely static and is mirrored all over the place. The majority of the site is the documentation. The documentation is automatically generated by applying a set of XSL stylesheets to the core documentation source which is a Docbook XML file. PDF and PostScript versions of the documentation are also generated from the Docbook.
Whenever a new release of Exim is cut, a new Docbook file is produced which contains the documentation changes, and then all of the documentation and site is regenerated from that single source.
Might be a good time to create some sub-groups so that we can focus more on our own areas of expertise. I'll throw up this as a division of tasks and a dev process but anyone feel free to add/remove or tell me it's a bad idea :P
*UI/UX design team* 1. Identify all pages and their content 2. Structure the pages into sections(probably the 5 already mentionned) and blocks(sub-sections like the "Announcements" or "Who uses Tor?" parts of the current page) as well as deciding how the user will navigate between sections and the resolution of the pages. 3. Create drawings of the structure
*Technical writers* 1. Write technically? Just joking. Create the content.
*Translators* 1. Translate the content
*Graphic design team* 1. Create mockups based on the UI specifications provided by the UI team for each page for both desktop and mobile versions.
*Front end implementation team* 1. Create the HTML based off the work of the UI team, simple HTML structure with (hopefully) no need to think about the presentation yet. 2. Create the CSS for the desktop and mobile versions. 3. Have a treat as the static site is done. 4. Create DHTML(non-ajax javascript) to enrich the pages all while letting graceful degradation occur for clients without javascript.
*Back-end developers* 1. Decide what technology is to be used and install/configure it, this might be the most problematic part as developers are a stubborn bunch, I'm a developer :) 2. Migrate the pages into the chosen solution(if necessary) 3. If necessary create a script triggered on content modification to e-mail translators and update the static page if a dynamic CMS is being used as well as pushing them onto the mirrors.
*Project coordinator(s)* 1. Coordinate the different teams and ensure everyone has the same vision and expectations.
Some additional technical requirements that may have been forgotten from the previous list or where just so obvious they weren't added: 1. At least two different UIs for mobile and desktop. 2. Ensure the site works in a completely static manner(no JS at all) 3. Automated pushing of static files to mirrors 4. Blogs, this was mentioned but I'm at a bit of a loss if this is a requirement or a separate project. 5. Store, I'm guessing it will stay as is on printfection.com but if the site gets a new look then the store will need a new design probably. 6. Forums, would this be something the site would like to have in the future? Of course this would need to be dynamic but if it is something that might be implemented in the future it might affect the choice of technology now.
Here is the development cycle I think would work well for the actual web pages of the project, I imagine it being iterative with one page/section/block at a time: *Phase 1* UI/UX team creates the structure Technical writers create the content
*Phase 2* Graphic designers create mock up based off structure and content Translators translate the content provided by the technical writers
*Phase 3* Front end developers create the HTML/CSS based off the mock up created in phase 2 as well as enriching with DHTML effects while ensuring it degrades nicely. Depending on the technical solution the pages might be broken down further in this phase to ensure content is not duplicated in the back end and can be reused for different pages.
*Phase 4* Back-end developers integrate the page into whatever technical solution was decided on
*Phase 5* Check all links and javascript is working as well as performance of CSS, JS and caching Page is tested in multiple browsers on multiple OSes on multiple devices to ensure the UI/UX is consistent on all of them
On Wed, Jan 8, 2014 at 3:04 PM, Rey Dhuny rey@spcshp.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
I think this a nice idea on paper however in terms of an MVP (Minimal Viable Product) I think it would make sense, in my opinion, to aim for one release with graceful degradation.
We could then focus our efforts efficiently then after release we can look at different _release flavours_, so to speak.
Just my 2p :)
Rey
-- reyhan.org
On 8 Jan 2014, at 19:51, ramiro tinoco rowend@rowend.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things El ene 8, 2014 10:00 a.m., "Silviu Riley" silviu.riley@gmail.com escribió:
I agree. Local files are much more secure than a local web server. Less attack profile for the computer starting TBB from USB for example.
Also less chance that something will fail (eg server fails to start).
Silviu. On Jan 8, 2014 10:12 AM, "Rey Dhuny" rey@spcshp.com wrote:
Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be
used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it’s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________ Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/08/2014 05:20 PM, Olssy wrote:
You also need a point for accessibilty.
Accessibility:
1) Visually impaired. 2) ease of finding things (This has been improved for the basic tor browser bundle but it is now harder to find the obfsproxy and more unusual programs that are downloadable from the site)
I'll be visiting a legally blind friend soon. If you want i can have her critique the site for her needs.
- --- Marina
Might be a good time to create some sub-groups so that we can focus more on our own areas of expertise. I'll throw up this as a division of tasks and a dev process but anyone feel free to add/remove or tell me it's a bad idea :P
*UI/UX design team* 1. Identify all pages and their content 2. Structure the pages into sections(probably the 5 already mentionned) and blocks(sub-sections like the "Announcements" or "Who uses Tor?" parts of the current page) as well as deciding how the user will navigate between sections and the resolution of the pages. 3. Create drawings of the structure
*Technical writers* 1. Write technically? Just joking. Create the content.
*Translators* 1. Translate the content
*Graphic design team* 1. Create mockups based on the UI specifications provided by the UI team for each page for both desktop and mobile versions.
*Front end implementation team* 1. Create the HTML based off the work of the UI team, simple HTML structure with (hopefully) no need to think about the presentation yet. 2. Create the CSS for the desktop and mobile versions. 3. Have a treat as the static site is done. 4. Create DHTML(non-ajax javascript) to enrich the pages all while letting graceful degradation occur for clients without javascript.
*Back-end developers* 1. Decide what technology is to be used and install/configure it, this might be the most problematic part as developers are a stubborn bunch, I'm a developer :) 2. Migrate the pages into the chosen solution(if necessary) 3. If necessary create a script triggered on content modification to e-mail translators and update the static page if a dynamic CMS is being used as well as pushing them onto the mirrors.
*Project coordinator(s)* 1. Coordinate the different teams and ensure everyone has the same vision and expectations.
Some additional technical requirements that may have been forgotten from the previous list or where just so obvious they weren't added: 1. At least two different UIs for mobile and desktop. 2. Ensure the site works in a completely static manner(no JS at all) 3. Automated pushing of static files to mirrors 4. Blogs, this was mentioned but I'm at a bit of a loss if this is a requirement or a separate project. 5. Store, I'm guessing it will stay as is on printfection.com but if the site gets a new look then the store will need a new design probably. 6. Forums, would this be something the site would like to have in the future? Of course this would need to be dynamic but if it is something that might be implemented in the future it might affect the choice of technology now.
Here is the development cycle I think would work well for the actual web pages of the project, I imagine it being iterative with one page/section/block at a time: *Phase 1* UI/UX team creates the structure Technical writers create the content
*Phase 2* Graphic designers create mock up based off structure and content Translators translate the content provided by the technical writers
*Phase 3* Front end developers create the HTML/CSS based off the mock up created in phase 2 as well as enriching with DHTML effects while ensuring it degrades nicely. Depending on the technical solution the pages might be broken down further in this phase to ensure content is not duplicated in the back end and can be reused for different pages.
*Phase 4* Back-end developers integrate the page into whatever technical solution was decided on
*Phase 5* Check all links and javascript is working as well as performance of CSS, JS and caching Page is tested in multiple browsers on multiple OSes on multiple devices to ensure the UI/UX is consistent on all of them
On Wed, Jan 8, 2014 at 3:04 PM, Rey Dhuny rey@spcshp.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things
I think this a nice idea on paper however in terms of an MVP (Minimal Viable Product) I think it would make sense, in my opinion, to aim for one release with graceful degradation.
We could then focus our efforts efficiently then after release we can look at different _release flavours_, so to speak.
Just my 2p :)
Rey
-- reyhan.org
On 8 Jan 2014, at 19:51, ramiro tinoco rowend@rowend.com wrote:
Maybe we could create 2 projects. One online with complete js and others things. The other project could be the simple version for user without js and other things El ene 8, 2014 10:00 a.m., "Silviu Riley" silviu.riley@gmail.com escribió:
I agree. Local files are much more secure than a local web server. Less attack profile for the computer starting TBB from USB for example.
Also less chance that something will fail (eg server fails to start).
Silviu. On Jan 8, 2014 10:12 AM, "Rey Dhuny" rey@spcshp.com wrote:
Sean Rafferty:
Just to clarify: technically tools like Jekyll or Sinatra could be
used because the server can be started wherever the site files are located whether it?s a USB stick or a laptop, correct?
I am of the opinion that starting a local server on a USB stick adds a level of complexity compared to distributing a bunch of flat files that Jekyll/Middleman generate.
Rey
-- reyhan.org
On Wednesday, 8 January 2014 at 15:09, Sean Rafferty wrote:
Just to clarify: technically tools like Jekyll or Sinatra could be used because the server can be started wherever the site files are located whether it?s a USB stick or a laptop, correct?
On Jan 8, 2014, at 9:34 AM, Lunar lunar@torproject.org wrote:
Sean Rafferty:
Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
Security concerns, ease to setup, ease of mirroring.
Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
Tor is used for censorship circumvention. Think about an USB stick with the Tor Browser Bundle, and a copy of the website. The website should be usable without requiring any access to the network so people can learn how to use Tor to reach the wider Internet.
-- Lunar lunar@torproject.org ________________________________________________________________________
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
________________________________________________________________________
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
________________________________________________________________________
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
________________________________________________________________________
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
Tor Website Team coordination mailing-list
To unsubscribe or change other options, please visit: https://lists.torproject.org/cgi-bin/mailman/listinfo/www-team
On Wed, Jan 08, 2014 at 08:21:40AM -0500, seanmrafferty@me.com wrote 1.8K bytes in 0 lines about: : Pardon my ignorance, but is the requirement for a static site a security concern or simply an ease-of-use issue?
The list in no particular order is security concern, scaling with limited hardware/virtual machines, and the ability to have an offline copy of the website.
: Another dumb question, but when you say the site needs to work offline, do you mean people can view the content without a web server, or that it must run on a local instance of a web sever and not require things like google's cdn version of query?
I ship copies of the website via CD/USB/DVD to people. They have a local browser. That's it. I include the release of TBB as part of the mirror, but no guarantee the person actually installs it. Most people fire up IE and browse the CD/DVD/USB.
andrew@torproject.is:
On Tue, Jan 07, 2014 at 06:41:02PM +0100, lunar@torproject.org wrote 2.5K bytes in 0 lines about: : * It should generate static web pages, ready to be mirrored by our : network of more than 70 mirrors.
The site also needs to work offline as well. This means self-contained and zero 3rd party requests. We don't want to host dynamic sites. We have 5 webservers capable of serving static content, nothing more.
And one more thing: a significant fraction of Tor users browse the web without JavaScript enabled. So while fancying the user experience is possible, everything should downgrade nicely.
-
Adam Gray -
andrew＠torproject.is -
Eric Schaefer -
Lunar -
Marina Brown -
Mike Cardwell -
Moritz Süß -
Olssy -
ramiro tinoco -
Rey Dhuny -
Sean Rafferty -
Silviu Riley