As of changeset:c7f4a832ebcfec93b826459c8074a6fe78b7315a the reorganization of the original site is basically done (ignoring some old pages and a few that I am uncertain of how/where they should fit in).

Once we are all happy with the url and navigation layout, the next task is to go through every single link on every single page of the site and ensure the link is correct. Internal links need to be in the form {{ site_url('url/of/page') }} (or the full url_for form for meetings/downloads/blog), and external I2P links need to be in the form http://{{ i2pconv('foobar.i2p') }}/baz (so that on the clearnet they are still accessible). After that, the last big task is to go through every page and set up translation tags per paragraph so that the site can be translated on Transifex (docs/how/intro is already done as an example). The two tasks can be done at the same time for each page.

The theme needs either further work (e.g. SOME designing of the non-front pages), adaption or replacement. I plan to put out requests for designs within I2P (zzz.i2p, forums, IRC, id3nt etc.) as well as maybe the clearnet.

The blog and meetings indexes need pagination.

The blog index needs real text at the top.

The support/performance page needs content (given that I have shifted the more technical future improvements list into a separate page). I'm wondering if eche|on's I2P speed blurb ​http://echelon.i2p/i2p/i2pspeed.txt could be adapted for this page?

Do the blog and meetings Atom feeds need adjusting so they don't show the entire blog entry or meeting summary, or is that okay? Given that the HTML would need to be intelligently shortened, it could be tricky...

There was a stub method added by welterde to the backend for a blog RSS feed. Is RSS needed as well as Atom? If so, it can be implemented using the same helper methods that the Atom feed methods use.

Any tasks relating to general page content should be done in upstream changeset:h:i2p.www and propagated across, BEFORE working on the links and translation tags (once they are done, propagating text changes will be a nightmare).

on /$LANG/site/support/htproxyports I would move IE8 to the top (sad but true) and add a Chrome section. Chrome iirc uses the OS proxy settings so maybe just rename the section to "Internet Explorer 8 or Chrome"

On the drop-down menu leading to the above: I would rename "Web browser configuration" -> "How to browse I2P" ( <-- minor nitpick, it's good enough as is)

maybe even "Support" -> "Help" on the tab name

$LANG/site/support/performance <-- not found, but it doesn't have to be there immediately

Support -> Forums : since forum.i2p is no longer accessible from clearnet, it should either not be there on the clearnet site or it should be marked somehow

There was a lot of good discussion about the revamp in meeting 213. Some of the points that were raised (I'm probably missing a few):

The SEO of the current site needs to be leveraged in the revamp.

The URLs of all old pages need to redirect to their new locations - using a permanent redirect should update our URLs in search engines etc.

So that mirrors don't suck away reputation:

Pages need a <link rel="canonical"> pointing to the main site.

All links to mirrors need to be rel="nofollow"

It would be good to generate a site map, which can then be uploaded to e.g. Google Webmaster Tools.

On that note, it would be good to claim www.i2p2.de on Google Webmaster Tools.

The decision to not have menu-opening items linked as well needs more thought.

Link some of them where relevant? (Previous behaviour, was decided against before)

Remove the <a> links from the menu-openers? I left them with <a> links because I thought it was necessary for the styling I mashed in to work.

Differentiate the menu-openers visually? That would be ideal IMHO.

Try integrating duck's original menu color into the mashed-in menubar CSS (to see if the overall look improves).

The text on the download page is reasonably important, so having direct links to the download files might not be a good idea. Maybe the "Download" menu could just become a "Download" link? (Though this would then mean that it was the only item on the menubar which is an actual link...)

Maybe the drop-down menus could just be buttons to top-level pages which contain the other links?

I don't like this idea much; to me the point of having a (good) drop-down menu is to make it much easier for a user to find what they want (in the shortest time possible); having to click through not-necessarily-obvious links on multiple pages to find what they want is not good IMHO.

The use of "/en/site" to mark a site page might need re-thinking - it increases the length of the URL.

Currently the backend uses the lang code first, and otherwise looks at the accept-languages header parameter.

changeset:99fb5fa0d9c136e32a66eccf9c9739aa01cad331 adds a <link rel="canonical"> to each page.

All mirrors linked in the footer already had rel="nofollow"

The site urls no longer contain "site/" - Flask was perfectly happy to distinguish between the "/<lang>/blog" etc. and "/<lang>/<page>" routes.

As per the Google recommendations above (as well as other related reading), the urls will still start with "/lang/" in order to ensure distinct pages for translations (which can then be prioritized by search engines in different regions).

After removing "site/" from the url above, the legacy pages route "/<page>" would not work ("/<page>.html" "/<page>_<lang>" etc. still did). To keep the urls nice, a custom url converter was added to match the lang part - as a result, the lang part of a url can now be in the form "en" or "en-us" (i.e. regionalization is possible).

The above additions were causing the site code to become unwieldy (all in a single .py file). The backend has now been refactored into python modules, additionally using a LazyView class to do lazy loading of the view code - this should speed up the website as only sections of the total codebase will now be loaded on a request.

The menubar CSS mashed into duck's theme has been tweaked to integrate better (both in usability and color), and I've made various other tweaks to try and improve the non-front-page pages. It's an improvement, but the theme as a whole still needs work.

I've removed the <a> links from the menu openers (the CSS is done with <div>s now), so the navbar now only has <a> links where needed for actual links.

The menu openers are now differentiated visually, so hopefully that improves usability.

The downloads list has been reworked to be clearer for users and easier to style. Some basic styling has been added in duck's and danimoth's themes.

Does the clearer downloads page remove the need for specific download links in the navbar?

Summary of things that need doing (at this stage) before the final link check and adding translation tags:

The LEGACY_PAGES_MAP in legacy.py needs filling out (diff the head to i2p.www to track where the pages went).

Sitemap generation - this could partly be done by crawling the pages/site/ dir for *.html, and then filled out with the other pages.

The blog index page needs work - text, layout, styling, whatever.

Ditto for the meetings index page.

/research needs filling out - I envisage this being a central page that we can direct academics to who are interested in studying I2P, which outines relevant information e.g. what the open questions in I2P are, what potential avenues of research could be pursued, what we as I2P developers would like to see studied (namely, everthing =P).

/research/papers is a list of academic I2P papers - should this be more in the style of an academic bibliography (since it is aimed at that demographic)?

/support/performance needs looking at - does it all make sense for the purpose of this page, or does it need tweaking?

I've added a template GNUnet comparison page, which I would like to get filled out (but this is not crucial, and the navbar link can be removed if it doesn't get done).

There is existing content that also needs work (this should be done in i2p.www and then propagate into the revamp).

As of changeset:42a10e0e62e3a0abd7895773b0fb1da198a68382 the LEGACY_PAGES_MAP has been filled out (so all the old site URLs now permanently redirect to the new ones), and the main site URLs have been standardized to use '-' to separate keywords (e.g. /en/docs/how/garlic-routing ) which should improve SEO as well as readability. The blog paths still use '_' as a spacer in the slugs, but they are converted to spaces when the slug is used as the blog post title, so I'm not sure if using '-'s there is going to work.

I'm starting to think that the current implementation of the blog - rendering a RST file that raw-includes a HTML file containing the blog post - is not a great method to use.

I'm guessing that welterde went for the RST file because it enabled some sort of metadata to be retrieved from the posts (which cannot be done with a Jinja2 rendered template AFAIK). But the blog posts should really be a single file - so if RST files are used then the old HTML files should be migrated over to Markdown.

The other problem is URL substitution - docutils does not seem to support any kind of template substitution, so e.g. the download url currently hard-written in each release post would remain so (and would link to the English download page). I wondered if the blog post could be rendered with Jinja2 first to do parameter substitution, and then rendering the resulting Markdown with docutils, but that seems somewhat clunky.

I'm currently looking into alternatives for the blog backend. Ideally a blog post could have metadata at the top which could be parsed easily, or a second file for storing metadata (both of these still require scanning the entire blog post directory to generate the blog index). Or maybe there could be a top-level file for post metadata. Or the post metadata could be cached to reduce regeneration frequency.

Decisions here could also influence the meetings page backend, which currently consists of a RST file with the meeting summary and a .log file with the meeting logs. If a better system is found for blog posts, I don't see why it could not be used for the meeting summaries as well (which would then mean that docutils could be dropped as a dependency).

changeset:74543c1cf04ef2b6f26f78139eca54d47b54baab contains a rework of the blog:

Added support for metadata in blog entries - date, author, category and excerpt

Modified blog/index.html and blog/entry.html templates to use metadata

Migrated the most recent post (0.9.4 Release) over to just a .rst file and added metadata, as a proof-of-concept

Still to resolve:

Every request of any page of the blog index, or the feed, results in all blog entries being rendered. Caching needs to be added here, probably with Flask-Cache which will integrate nicely (and can be hooked into memcached or whatever backend the server has).

Currently the title used on the blog index pages is the one taken from the slug of the page (its filename). But there is now access to the actual title of the post (due to every entry being rendered) - should this be used?

The date on the blog index pages is the one taken from the slug of the page (its directory path). But a date can now be added as metadata, and this is currently displayed on the entry page. Which should be preferred? Is there any point in having date metadata? Might there be use in having metadata for the last time the post was updated, while using the date from the slug as the date of post?

Once the above is decided on and finalized, the old blog entries should be migrated over.

An incidental question: would the url /lang/blog/post/XXXX/XX/XX/slug be preferable to the current /lang/blog/entry/XXXX/XX/XX/slug ?

The date issue above has been "resolved" in that the 'date' metatag is used preferentially, but falls back on the date taken from the slug. Additionally, the blog RST files are now pre-rendered with Jinja2, meaning that normal template tags can be used (e.g. for generation of site URLs). This also means that the blog posts can be tagged for translation like the main site pages.

I have migrated over the 0.9.3 release post to the new format, and added translation tags to it and the 0.9.4 release post; between them, the general layout for blog posts is now well-defined, and future posts will follow this layout. The earlier blog pages still render correctly so I won't be migrating them (as there are other laborious tasks remaining), but anyone is welcome to migrate them across to pick up the extra features.

As of changeset:cd2b4484fd02a2a1f370dc607bbfc26e2379b6cc the blog and meetings views (index pages, individual entries and feesd) all have ten minute caching, which is enabled when the server operator configures the cache for whatever backend they have.

Additionally, the rendered blog titles are now taken from the blog post RST instead of the slug, so that they can be translated; the slug now only affects the URL.

Sitemaps are now cached per language, and the blog posts have been renamed to use hyphens instead of underscores.

Additionally, after looking at the stats on Google Webmaster Tools to see which pages are more popular/viewed/clicked/linked/etc, I pushed changeset:0faeddbcbab6b33ebf3295c98b687b390b4dc51b which reorganizes several URLs:

renamed i2p2www/pages/site/about/comparison

to i2p2www/pages/site/comparison

renamed i2p2www/pages/site/about/contact.html

to i2p2www/pages/site/contact.html, /lang/contact

renamed i2p2www/pages/site/support/browser-config.html

to i2p2www/pages/site/about/browser-config.html

renamed i2p2www/pages/site/support/faq.html

to i2p2www/pages/site/faq.html

renamed i2p2www/pages/site/support/glossary.html

to i2p2www/pages/site/about/glossary.html

renamed i2p2www/pages/site/support/performance

to i2p2www/pages/site/about/performance

This reorganization removes the /lang/support/* URL subcategory entirely (nullifying the above question of shifting it to /lang/help/*) and makes the more "visible" URLs shorter (/lang/faq, /lang/comparison/*).

As of this point, I think the revamp is about ready to go. The last blocking tasks are to check every single page of the site for valid URLs and to tag every single site page for translations. I'll start this now.

The translation tagging is progressing - slowly (it's hell on my hands >_<) but aside from the Documentation, most of the site is done.

On another front, the revamp now supports mobile browsers much better. The required tags have been added to <head> and duck's theme now has a mobile.css (other themes could follow suit). It is displayed on browsers with a width less than 768px, so it can be previewed in desktop browsers.

I just visited the mobile site on a desktop broswer (midori), safari on an ipod touch, and the stock android browser (the latter two via i2p.us) The site works fine from the desktop but on the mobile browsers the navigation bar is unusable. On the ipod none of the links work except the link to the download page, and on the android the titles expand correctly, however the 3rd tier links are unclickable, the broswer just selects the 2nd tier link behind it and expands the appropriate menu. I have only looked at the menu bar so far however i will report back with other bugs on the mobile site as i discover them.

I just visited the mobile site on a desktop broswer (midori), safari on an ipod touch, and the stock android browser (the latter two via i2p.us) The site works fine from the desktop but on the mobile browsers the navigation bar is unusable. On the ipod none of the links work except the link to the download page, and on the android the titles expand correctly, however the 3rd tier links are unclickable, the broswer just selects the 2nd tier link behind it and expands the appropriate menu. I have only looked at the menu bar so far however i will report back with other bugs on the mobile site as i discover them.

Thanks for looking at it. I didn't realise it wasn't working that well, but I'd only tested on Opera Mobile for Android. I do recall having the 3rd tier issue, but the CSS I'm using for the menu (​http://astuteo.com/mobilemenu) originally only supported up to 2nd tier, so it probably requires some refining. Odd that it doesn't work at all for iOS - the CSS's webpage specifically shows an iPhone _ I probably messed up when migrating the CSS to the revamp though; I'll check.

The site has been (almost completely) tagged for translations; trolly has translated 26% into Spanish already, and other languages are trickling in. URLs have also been updated and checked (but will be checked again after the site is launched on ​http://geti2p.net and before ​http://www.i2p2.de is redirected).

Recent changes include propagating updates from the current website, and changes to the download and mirror selection pages from ticket #463. Mobile CSS has not been further tested other than confirming that it does work on Opera Mobile for Android, mostly... Clicking a 3rd tier item does correctly select it, but opening a 2nd or 3rd tier sub-menu and then clicking on a 1st or 2nd tier item below it selects an incorrect item - the selected item is the one that would have been in the clicked position had the sub-menu not been open. This might be the issue referred to in comment 24.

Other points that still require work: the blog (style and structure), the theme (general styling, desktop tweaks, mobile improvements).

Optimistically adding this to the 0.9.6 milestone (pending welterde having free time).

welterde put the revamp up live at a test domain. I have updated the legacy mapping and run checks for broken links. There are many dead links in the old status posts, but I cannot update them because the posts are PGP signed. On the rest of the site there are now only a handful of problematic external links. And AFAICT all site-internal links are valid.