*please* revert to old privacytools.io website - with all elements as one singe wall #882

New Issue

jonah · 2019-04-24T21:08:18Z

qubecub commented

2019-04-24 21:08:18 +00:00

(Migrated from github.com)

Some time ago privacytools.io change the layout of the site introducing "categorized" view with drill-down sections to look up specific group of security applications, technologies or topics. This is very bad idea.
The way privacytools site was structured initially was great as it allowed me to just scroll one page and I could identify differences, new additions at the first glance. Now, with the new design it takes ages to navigate, tons of clicks, back and forward navigation. It is just so impractical.

I urge you, PLEASE go back to the old single-wall design of your site for the privacy applications you're presenting.

BTW. I love what you do, I love the content, I just can't help but hating the new design.

I would be immensely grateful (as would many other users as I saw on multiple forums) if you do revert to the old privactytools site design.

Thank you!

Some time ago privacytools.io change the layout of the site introducing "categorized" view with drill-down sections to look up specific group of security applications, technologies or topics. This is *very* bad idea. The way privacytools site was structured initially was great as it allowed me to just scroll one page and I could identify differences, new additions at the first glance. Now, with the new design it takes ages to navigate, tons of clicks, back and forward navigation. It is just so impractical. I *urge* you, *PLEASE* go back to the old single-wall design of your site for the privacy applications you're presenting. BTW. I love what you do, I love the content, I just can't help but hating the new design. I would be immensely grateful (as would many other users as I saw on multiple forums) if you do revert to the old privactytools site design. Thank you!

👍 2

Mikaela commented

2019-04-24 21:10:59 +00:00

(Migrated from github.com)

You can still use https://www.privacytools.io/classic/ .

Mikaela commented

2019-04-24 21:13:29 +00:00

(Migrated from github.com)

Reopening, because I cannot see where to find /classic/ without knowing it's there, maybe it should be an arrow next to the home button to find it?

qubecub commented

2019-04-24 21:17:04 +00:00

(Migrated from github.com)

Hi Mikaela,
You're the bearer of great news. I didn't know the 'classic' tag supports the old view. In this case my world is whole again :)
Many thanks!
qubecub

Hi Mikaela, You're the bearer of great news. I didn't know the 'classic' tag supports the old view. In this case my world is whole again :) Many thanks! qubecub

❤️ 1

qubecub commented

2019-04-24 21:17:31 +00:00

(Migrated from github.com)

Just tested it and it works ! Perfect.

🎉 1

five-c-d commented

2019-04-25 01:45:32 +00:00

(Migrated from github.com)

I cannot see where to find /classic/ without knowing it's there

It is linked to from the homepage, but very "subtle" and easy to miss. I found it but only after like a month. Right under the six big super-categories (provider / browser / SW / OS / svcs / donate) there is a line of text with a hyperlink:

ℹ️ Prefer the classic site? It's still around!

Right under that is a huge "Privacy? I don't have anything to hide" section header. So the small line of normal-size text gets a little lost-in-the-visual-sea and I suspect many people miss it. I also don't think "the classic site" is a good description... recommend saying something like this:

ℹ️ Want ALL the recommendations

filling **One GIANT Page**

for easy scrolling and printing?

:-) _{or you could be a wee bit more subtle}

But the current link in normal fontface, it a bit too subtle, methinks

> I cannot see where to find /classic/ without knowing it's there It is linked to from the homepage, but very "subtle" and easy to miss. I found it but only after like a month. Right under the six big super-categories (provider / browser / SW / OS / svcs / donate) there is a line of text with a hyperlink: * :information_source: Prefer the classic site? It's <a href="https://www.privacytools.io/classic/">still around</a>! Right under that is a huge "Privacy? I don't have anything to hide" section header. So the small line of normal-size text gets a little lost-in-the-visual-sea and I suspect many people miss it. I also don't think "the classic site" is a good description... recommend saying something like this: ##       :information_source: Want *ALL* the recommendations ##           filling <a href="https://www.privacytools.io/classic/">**One *GIANT* Page**</a> ##              for easy scrolling and printing? :-)    or you could be a *wee* bit more subtle But the current link in normal fontface, it a bit too subtle, methinks

ThatLurker commented

2019-04-25 05:38:45 +00:00

(Migrated from github.com)

How about adding a button titled "Classic" next to the language dropdown in the menu, so you can always switch to the classic page.

five-c-d commented

2019-04-25 05:47:08 +00:00

(Migrated from github.com)

I like the button-idea, but I think the button-name should be "OnePage" or maybe "OneBigPage" instead of classic. People that have never visited before won't necessarily know what the classic site was, but they will definitely understand what the OneBigPage site means

Mikaela commented

2019-04-25 06:04:20 +00:00

(Migrated from github.com)

What do you think of "all in one page" instead of "one big page"?

👍 1

abbluiz commented

2019-04-25 06:56:18 +00:00

(Migrated from github.com)

There is also the option of something like "save/print this website", but "all in one page" is probably enough. The idea would be changing from classic to something more clear.

ghost commented

2019-04-25 14:25:52 +00:00

(Migrated from github.com)

create a sitemap as well, perhaps?

There is a convention for this.. when a website makes navigation deep or complex (e.g. with structural navigation), they have a "sitemap" which then dispenses with uncommon jargon and shows the user a flat structure. A site map would be useful, although it's not exactly what the OP requested. It's good to have this because the site map is generally free of images and fast loading (read: less server stress). Having an index of everything like this is also useful for developers who want to cut to the chase.

Classic Flat structure

I'm not a fan of calling it "classic" because it implies obsolescence and also assumes the visitor knows what the past layout was like previously. Instead, I would call it a "flat structure" or "unstructured". "Single page" or "One big page" or "all in one page" (as suggested) works too.

move "web browsers"

Web browsers are software.. it's strange they are listed separately at the top level.

## create a sitemap as well, perhaps? There is a convention for this.. when a website makes navigation deep or complex (e.g. with [structural navigation](https://www.oreilly.com/library/view/designing-web-navigation/9780596528102/ch04.html)), they have a "***sitemap***" which then dispenses with uncommon jargon and shows the user a flat structure. A site map would be useful, although it's not exactly what the OP requested. It's good to have this because the site map is generally free of images and fast loading (read: less server stress). Having an index of everything like this is also useful for developers who want to cut to the chase. ## ~~Classic~~ Flat structure I'm not a fan of calling it "*classic*" because it implies obsolescence and also assumes the visitor knows what the past layout was like previously. Instead, I would call it a "*flat* structure" or "unstructured". "Single page" or "One big page" or "all in one page" (as suggested) works too. ## move "web browsers" Web browsers *are* software.. it's strange they are listed separately at the top level.

👍 1

five-c-d commented

2019-04-25 14:59:05 +00:00

(Migrated from github.com)

Browsers and OSes are top-level because most people HAVE to have them. Not everybody needs voip, not everybody needs webmail even, but 99.99% of people need a browser and need an OS. Please open a new thread though, this one is about the sitemap

sitemap

This is a genius name, and I'm kicking myself for not having thought of it :-) Nice work.

Right now the /classic portion is just a bunch of server-side-transcludes, which pulls in each of the section'd off contents into the traditional ordering. But we can make that better-named by changing /classic --> /sitemap, and then make it look like a traditional sitemap, with some CSS. The normal webpages would use the regular CSS file, but on the /sitemap portion there would be a special sitemap.css file that is only loaded there... which makes everything easier to read e.g. changing from h1+h2 styling down to h4+h5 styling to save space, changing from top1 top2 top3 in big boxes to an ul li li li /ul type structure, etc.

"all in one page" instead of "one big page"

@Mikaela -- sure that is fine. Anything but the ambiguous 'classic' ... we just need something that is clear and direct, like abbluiz says.

I like sitemap the best now, though. @libBletchley also suggests "Single Page" which is the most succinct without using any jargon. So maybe name the URL /sitemap instead of /classic, and have the button say "Single Page version"? or just have the button say "Sitemap" which I'm guessing most people know ... and if they don't know it the term is almost self-defining as The Map Of This Site.

Browsers and OSes are top-level because most people HAVE to have them. Not everybody needs voip, not everybody needs webmail even, but 99.99% of people need a browser and need an OS. Please open a new thread though, this one is about the sitemap > sitemap This is a genius name, and I'm kicking myself for not having thought of it :-) Nice work. Right now the /classic portion is just a bunch of server-side-transcludes, which pulls in each of the section'd off contents into the traditional ordering. But we can make that better-named by changing /classic --> /sitemap, and then make it look like a traditional sitemap, with some CSS. The normal webpages would use the regular CSS file, but on the /sitemap portion there would be a special sitemap.css file that is only loaded there... which makes everything easier to read e.g. changing from h1+h2 styling down to h4+h5 styling to save space, changing from top1 top2 top3 in big boxes to an ul li li li /ul type structure, etc. > "all in one page" instead of "one big page" @Mikaela -- sure that is fine. Anything but the ambiguous 'classic' ... we just need something that is clear and direct, like abbluiz says. I like sitemap the best now, though. @libBletchley also suggests "Single Page" which is the most succinct without using any jargon. So maybe name the URL /sitemap instead of /classic, and have the button say "<a href="https://www.privacytools.io/sitemap/">Single Page</a> version"? or just have the button say "Sitemap" which I'm guessing most people know ... and if they don't know it the term is almost self-defining as The Map Of This Site.

ThatLurker commented

2019-04-25 18:53:30 +00:00

(Migrated from github.com)

Would something like this look good? Screenshot 60

Code for this

 <li class="nav-item">
  <a class="nav-link" href="/classic/">Classic<i class="fas fa-archive"></i></a>
 </li>

Would something like this look good? <img width="469" alt="Screenshot 60" src="https://user-images.githubusercontent.com/1533244/56760685-66e39880-67a4-11e9-85cc-443637d2eb0c.png"> <details> <summary>Code for this</summary> ```html <li class="nav-item"> <a class="nav-link" href="/classic/">Classic</a> </li> ``` </details>

jonah commented

2019-04-25 19:00:51 +00:00

I think the navbar is getting a bit cluttered and not the best space for new options (especially with #872).

👍 1

jonah commented

2019-04-29 22:06:37 +00:00

I'm not a fan of calling it "classic" because it implies obsolescence

(that's the point)

I think the current link on the homepage is good enough actually, so I'm closing this. It may not be obvious why we moved to multiple pages currently, but hopefully in the future things will be more clear.

Multiple pages is good for permalinks, both SEO and sharing wise. Compared with anchors, which don't work super well, linking someone to /providers/vpn/ will always make sure they reach the VPN section.
Long-term, the pages will be a lot more detailed, with information we wouldn't be able to fit on the highly-simplified single page layout. This is a very work in progress concept for example, but we could do something like this with our recommendations.

This will allow us to include more detail about the pros and cons of different tools we recommend, because they're not all perfect (see: #856 and #779 for an example of two heated arguments about Firefox and Signal).
Along the same lines, we'll be able to include information about the tools that aren't necessarily relevent to every user and would clutter up the single-page layout, but would be great if they existed on the smaller subpages. Information on how to use a VPN for example, would be great on the VPN page. I think that's the new direction I want to go in with guides.privacytools.io rather than put them all on a separate website entirely.

> I'm not a fan of calling it "classic" because it implies obsolescence (that's the point) I think the current link on the homepage is good enough actually, so I'm closing this. It may not be obvious why we moved to multiple pages currently, but hopefully in the future things will be more clear. 1. Multiple pages is good for permalinks, both SEO and sharing wise. Compared with anchors, which don't work super well, linking someone to `/providers/vpn/` will always make sure they reach the VPN section. 2. Long-term, the pages will be a lot more detailed, with information we wouldn't be able to fit on the highly-simplified single page layout. This is a very work in progress concept for example, but we could do something like this with our recommendations. ![image](https://user-images.githubusercontent.com/3637842/56929743-0ef8aa80-6aa0-11e9-8329-0185cae9ac95.png) This will allow us to include more detail about the pros and cons of different tools we recommend, because they're not all perfect (see: #856 and #779 for an example of two heated arguments about Firefox and Signal). Along the same lines, we'll be able to include information *about* the tools that aren't necessarily relevent to every user and would clutter up the single-page layout, but would be great if they existed on the smaller subpages. Information on how to *use* a VPN for example, would be great on the VPN page. I think that's the new direction I want to go in with [guides.privacytools.io](https://github.com/privacytoolsIO/guides.privacytools.io) rather than put them all on a separate website entirely.

five-c-d commented

2019-04-29 23:41:52 +00:00

(Migrated from github.com)

the pages will be a lot more detailed

Which is great.

pros and cons of different tools

Superb.

information about the tools
that aren't necessarily relevent to every user
and would clutter up the single-page layout
but would be great if they existed on the smaller subpages

Ah. Here is where I get nervous. Mostly I see privacyToolsIO as a way to give somebody that is using chrome on windows 10 home, unencrypted emails, unencrypted calls, no vpn, no FDE, has a facebook and spills their guts, has a twitter and spills their guts, et cetera, etc ...

one place where they can, in half an hour of skipping down The One Big Bunch Of Listings, gain the following benefits:

the idea that maybe everything they are doing is wrong
some education about why they are doing it wrong
some quick top3 hints that won't usually bite them

For folks like that, installing firefox and a couple plugins, using qubes OS or TailsOS for some of their tasks, free-as-in-beer encrypted webmail, signalapp or if they need encrypted confcalls wireapp, protonvpn (which is a good way to start since it is free-as-in-beer), some kind of simple cryptosystem (might be bitlocker or might be veracrypt-hidden-folder or might be cryptomator or whatever), firefoxSend for transfers that encrypted webmail and signalapp cannot manage, and the fediverse alternatives....

Even if they only manage to change a couple things their first visit, that is a win. And usually they will be horrified, and want more advice. Typically the just get encouraged to keep going through the list, and upgrading their tools one by one, and then loop back and go through the list AGAIN and see if they missed anything.

This is very difficult to imagine them doing, if they have to do a bunch of clicking around, and if each of the subpages has a lot of verbosity: step-by-step guides to utilizing VPNs are excellent when the enduser needs it, but distracting if they are just looking for a summary of what steps they can take Right Now and they only have a few minutes to spin through the website. Especially if they are only doing it because I told them, in no uncertain terms "you are doing almost everything wrong so please start here it will clue you in"

obsolescence

(that's the point)

There still seems to be room for a summary-page, which is not obsolete by the details found in the pros-n-cons and guidebook sub-pages. The summary-page can give an overview of these-are-the-things-you-can-do-right-now, with links to more details. As well as, basic philosophical grounding (refuting the I-am-a-good-person-with-nothing-to-hide-who-cares-about-privacy mistake is usually very critical to get out of the way quite early on).

Depends on the intended audience of the website though. Is it not supposed to be usable by everyday endusers who are just learning about privacy and the tools to achieve it, perhaps for the first time? These folks are hard to keep coming back, if their eyes glaze over.

> the pages will be a lot more detailed Which is great. > pros and cons of different tools Superb. > information _about_ the tools > that aren't necessarily relevent to every user > and would clutter up the single-page layout > but would be great if they existed on the smaller subpages Ah. Here is where I get nervous. Mostly I see privacyToolsIO as a way to give somebody that is using chrome on windows 10 home, unencrypted emails, unencrypted calls, no vpn, no FDE, has a facebook and spills their guts, has a twitter and spills their guts, et cetera, etc ... ***one*** place where they can, in half an hour of skipping down The One Big Bunch Of Listings, gain the following benefits: 1. the idea that maybe everything they are doing is wrong 2. some education about why they are doing it wrong 3. some quick top3 hints that won't usually bite them For folks like that, installing firefox and a couple plugins, using qubes OS or TailsOS for some of their tasks, free-as-in-beer encrypted webmail, signalapp or if they need encrypted confcalls wireapp, protonvpn (which is a good way to start since it is free-as-in-beer), some kind of simple cryptosystem (might be bitlocker or might be veracrypt-hidden-folder or might be cryptomator or whatever), firefoxSend for transfers that encrypted webmail and signalapp cannot manage, and the fediverse alternatives.... Even if they only manage to change a couple things their first visit, that is a win. And usually they will be horrified, and want more advice. Typically the just get encouraged to keep going through the list, and upgrading their tools one by one, and then loop back and go through the list AGAIN and see if they missed anything. This is very difficult to imagine them doing, if they have to do a bunch of clicking around, and if each of the subpages has a lot of verbosity: step-by-step guides to utilizing VPNs are excellent when the enduser needs it, but distracting if they are just looking for a summary of what steps they can take Right Now and they only have a few minutes to spin through the website. Especially if they are only doing it because I told them, in no uncertain terms "you are doing almost everything wrong so please start here it will clue you in" >> obsolescence > > (that's the point) There still seems to be room for a summary-page, which is not obsolete by the details found in the pros-n-cons and guidebook sub-pages. The summary-page can give an overview of these-are-the-things-you-can-do-right-now, with links to more details. As well as, basic philosophical grounding (refuting the I-am-a-good-person-with-nothing-to-hide-who-cares-about-privacy mistake is usually very critical to get out of the way quite early on). Depends on the intended audience of the website though. Is it not supposed to be usable by everyday endusers who are just learning about privacy and the tools to achieve it, perhaps for the first time? These folks are hard to keep coming back, if their eyes glaze over.

jonah commented

2019-04-30 00:05:41 +00:00

Okay.

(Click me) Actually these new cards will be backwards-compatible with the old "quick top3" recommendations on the classic site.

That means they can appear as either...

or...

Depending on the page you're on, either the new browser sub-page or the old "classic" site. And using the same exact code! So we'll be able to keep the single-page layout up-to-date as we make changes to the newer cards.

And building off of that, I think I would be fine with renaming /classic/ to something like /summary/. I'm now thinking that keeping the single-page layout is a good idea, simply as something to quickly look through. We could then include a "read more" link below each section on the summary page that links to the subpages, which will have more in-depth details on all the subject: Pros and Cons, and the information about the tools I mentioned. I think they definitely have a place on our website, it just wouldn't work on the previous layout, which was already too cluttered.

Also on the to-do list is adding better navigation between the subpages. So we'll have something like a previous and next button at the bottom of each page, so people can click through them like pages in a book, which is a fairly intuitive way of navigating. That's probably what I'll tackle next after I finalize these extended recommendation cards.

Okay. <details><summary>(Click me) Actually these new cards will be backwards-compatible with the old "quick top3" recommendations on the classic site.</summary> That means they can appear as either... ![image](https://user-images.githubusercontent.com/3637842/56934146-99490a80-6ab0-11e9-8520-c54a452ed08d.png) or... ![image](https://user-images.githubusercontent.com/3637842/56934176-b1b92500-6ab0-11e9-94d0-e522248af648.png) Depending on the page you're on, either the new browser sub-page or the old "classic" site. And using the same exact code! So we'll be able to keep the single-page layout up-to-date as we make changes to the newer cards.</details> And building off of that, I think I would be fine with renaming `/classic/` to something like `/summary/`. I'm now thinking that keeping the single-page layout is a good idea, simply as something to quickly look through. We could then include a "read more" link below each section on the summary page that links to the subpages, which will have more in-depth details on all the subject: Pros and Cons, and the information about the tools I mentioned. I think they definitely have a place on our website, it just wouldn't work on the previous layout, which was already too cluttered. Also on the to-do list is adding better navigation between the subpages. So we'll have something like a previous and next button at the bottom of each page, so people can click through them like pages in a book, which is a fairly intuitive way of navigating. That's probably what I'll tackle next after I finalize these extended recommendation cards.

five-c-d commented

2019-04-30 00:17:34 +00:00

(Migrated from github.com)

to something like /summary

Still recommend sitemap ;-) but yes, summary is fine

Would also argue that there is room for the basic pros-n-cons right on the summary page, as long as they are strictly limited in number/quantity. (This is just a quick example off the top of my head, and note that ~~pro#2~~ con#2 of wireapp is obsolete, they just successfully exorcised FirebaseAnalytics from their APK -- nice!) There would be more room for a detailed comparison-table, covering all the crucial stuff, on the sub-page dedicated to messengers

I'm imagining the summary-page will just be top3 after top3, with some interspersed prose where needed ("I've got nothing to hide" goes on the summary-page whereas "what is a warrant-canary" probably belongs on the VPN-details-page perhaps?)

p.s. If there is a better github-issue to discuss what should go on the summary-page slash sitemap page, we can move there. I actually made the imagefile above some time ago for posting to the pros-n-cons github issue from last November, to revive it, but I am still drafting that humongo-posting. Sounds like you are way ahead of me :-)

> to something like `/summary` Still recommend sitemap ;-) but yes, summary is fine ![privacyToolsIO_pro_vs_con](https://user-images.githubusercontent.com/42419492/56934675-820b1c80-6ab2-11e9-8871-a829dedd353e.jpg) Would also argue that there is room for the basic pros-n-cons right on the summary page, as long as they are strictly limited in number/quantity. (This is just a quick example off the top of my head, and note that <s>pro#2</s> <ins>con#2</ins> of wireapp is obsolete, they just successfully exorcised FirebaseAnalytics from their APK -- nice!) There would be more room for a detailed comparison-table, covering all the crucial stuff, on the sub-page dedicated to messengers I'm imagining the summary-page will just be top3 after top3, with some interspersed prose where needed ("I've got nothing to hide" goes on the summary-page whereas "what is a warrant-canary" probably belongs on the VPN-details-page perhaps?) p.s. If there is a better github-issue to discuss what should go on the summary-page slash sitemap page, we can move there. I actually made the imagefile above some time ago for posting to the pros-n-cons github issue from last November, to revive it, but I am still drafting that humongo-posting. Sounds like you are way ahead of me :-)

jonah commented

2019-04-30 00:25:10 +00:00

Still recommend sitemap

That doesn't really make sense, sitemap is already like, a well known term in web development, i.e. https://www.privacytools.io/sitemap.xml :)

If there is a better github-issue to discuss what should go on the summary-page slash sitemap page, we can move there

I don't think so, but that should probably be made. I was imagining removing stuff from the summary like "Our VPN Provider Criteria", "What is a warrant canary?", "Browser Fingerprint...", the FF tweaks, etc..... basically everything that isn't 1) a tool recommendation or 2) very very top-level information like the "Privacy? I don't have anything to hide." introduction section.

But if you want to make that issue we can discuss that more there.

> Still recommend sitemap That doesn't really make sense, sitemap is already like, a well known term in web development, i.e. https://www.privacytools.io/sitemap.xml :) > If there is a better github-issue to discuss what should go on the summary-page slash sitemap page, we can move there I don't think so, but that should probably be made. I was imagining removing stuff from the summary like "Our VPN Provider Criteria", "What is a warrant canary?", "Browser Fingerprint...", the FF tweaks, etc..... basically everything that isn't 1) a tool recommendation or 2) very *very* top-level information like the "Privacy? I don't have anything to hide." introduction section. But if you want to make that issue we can discuss that more there.

five-c-d commented

2019-05-03 04:25:53 +00:00

(Migrated from github.com)

That doesn't really make sense

Oh sure it does, if you understand what I'm aiming at. I'm suggesting you generate the 'summary' HTML from the (also generated presumably) sitemap-dataset.

here is XML, which with XSL can become human-renderable, not just search-crawler-friendly

These are the leafnodes of your sitemap.xml ==

privacytools.io/providers/vpn
privacytools.io/browsers
privacytools.io/providers/email
privacytools.io/software/email
privacytools.io/providers/search-engines
privacytools.io/software/im
privacytools.io/software/voip
privacytools.io/software/file-sharing
privacytools.io/providers/cloud-storage
privacytools.io/software/cloud
privacytools.io/providers/hosting
privacytools.io/software/file-sync
privacytools.io/software/passwords
privacytools.io/software/calendar-contacts
privacytools.io/software/encryption-tools
privacytools.io/software/networks
privacytools.io/providers/social-networks
privacytools.io/providers/dns
privacytools.io/software/notebooks
privacytools.io/providers/paste
privacytools.io/software/productivity
privacytools.io/operating-systems
privacytools.io/contact
privacytools.io/donate
privacytools.io/privacy-policy

With a bit of simplistic XSL you could take that sitemap.XML as input, and produce this as the output ==

{% include sections/header.html %}  <!-- missing and tbd --> 
{% include sections/quotes.html %}  <!-- missing and tbd --> 
{% include sections/fourteen-eyes.html %}  <!-- elided? --> 
{% include sections/key-disclosure-law.html %}  <!-- elided --> 

{% include sections/vpn.html %}
{% include sections/warrant-canary.html %}   <!-- elided --> 
{% include sections/browser-recommendation.html %}
{% include sections/browser-fingerprint.html %}   <!-- elided --> 
{% include sections/browser-webrtc.html %}   <!-- elided --> 
{% include sections/browser-addons.html %}   <!-- elided? --> 
{% include sections/browser-tweaks.html %}   <!-- elided --> 
{% include sections/email-providers.html %}
{% include sections/email-clients.html %}
{% include sections/email-alternatives.html %}   <!-- elided? --> 
{% include sections/search-engines.html %}
{% include sections/instant-messenger.html %}
{% include sections/voice-video-messenger.html %}
{% include sections/file-sharing.html %}
{% include sections/cloud-storage.html %}
{% include sections/selfhosted-cloud.html %}
{% include sections/hosting-provider.html %}
{% include sections/file-sync.html %}
{% include sections/password-managers.html %}
{% include sections/calendar-contacts-sync.html %}
{% include sections/file-encryption.html %}
{% include sections/self-contained-networks.html %}
{% include sections/social-networks.html %}
{% include sections/dns.html %}
{% include sections/notebooks.html %}
{% include sections/paste-services.html %}
{% include sections/productivity-tools.html %}
{% include sections/operating-systems.html %}
{% include sections/live-operating-systems.html %}
{% include sections/mobile-operating-systems.html %}
{% include sections/android-addons.html %}
{% include sections/router-firmware.html %}
{% include sections/windows10.html %}   <!-- elided? --> 

{% include sections/privacy-resources.html %}
{% include sections/participate.html %}

aka the bodycontents of 44acee2ef4/pages/old.html would be generated from the sitemap.xml and then become the /summary

this is just a way to make maintenance easier ... the difference is not enduser-visible

But the difference would be, compared to /classic, that the new /summary page would primarily concentrate on the "top3 cards" and most of the detailed guides (e.g. about:config tweaks) would not be on /summary at all, only appearing on the /browsers subpage itself.

You can also get the same effect "manually" by hand-creating /summary and hand-updating it. Which might be less work than writing a bit of XSL, and would certainly be easier to update perhaps? But no, it definitely makes sense, if you have sitemap.xml, to use that to generate a human-readable /sitemap (or if you prefer /summary as the name). Dunno whether @libBletchley was suggesting an XSLT implementation approach when they recommended 'sitemap' as a name but that was immediately what came to my mind anyways

Doesn't matter to the enduser aka the readership, whether you want to generate /summary from sitemap+xsl, or hand-compose the contents of /summary ... and indeed, doesn't matter whether you want to call it /summary as opposed to /sitemap since they both get the point across. But since you were trying to make the classic-one-big-page-layout obsolete, I figured you would be interested in auto-generating the /summary ? Definitely up to you though :-) Like I say, the readership won't see any difference, and I am only suggesting a pathway that might reduce maintenance-burden... depends on how wildly you envision the /summary contents diverging from the sitemap.xml leafnodes, as to whether that hypothetical burden-reduction would materialize.

...that [issue] should probably be made. I was imagining removing stuff from the summary like "Our VPN Provider Criteria", "What is a warrant canary?"

Yes, agreed on both. For the first thing, I create #896 with some strikethru to indicate what I think can be elided on the summary-page, including most of what you wanted zapped

> That doesn't really make sense Oh sure it does, if you understand what I'm aiming at. I'm suggesting you generate the 'summary' HTML from the (also generated presumably) sitemap-dataset. <details><summary>here is XML, which with XSL can become human-renderable, not just search-crawler-friendly</summary> These are the leafnodes of your sitemap.xml == * privacytools.io/providers/vpn * privacytools.io/browsers * privacytools.io/providers/email * privacytools.io/software/email * privacytools.io/providers/search-engines * privacytools.io/software/im * privacytools.io/software/voip * privacytools.io/software/file-sharing * privacytools.io/providers/cloud-storage * privacytools.io/software/cloud * privacytools.io/providers/hosting * privacytools.io/software/file-sync * privacytools.io/software/passwords * privacytools.io/software/calendar-contacts * privacytools.io/software/encryption-tools * privacytools.io/software/networks * privacytools.io/providers/social-networks * privacytools.io/providers/dns * privacytools.io/software/notebooks * privacytools.io/providers/paste * privacytools.io/software/productivity * privacytools.io/operating-systems * privacytools.io/contact * privacytools.io/donate * privacytools.io/privacy-policy With a bit of simplistic XSL you could take that sitemap.XML as input, and produce this as the output == ``` {% include sections/header.html %}  {% include sections/quotes.html %}  {% include sections/fourteen-eyes.html %}  {% include sections/key-disclosure-law.html %}  {% include sections/vpn.html %} {% include sections/warrant-canary.html %}  {% include sections/browser-recommendation.html %} {% include sections/browser-fingerprint.html %}  {% include sections/browser-webrtc.html %}  {% include sections/browser-addons.html %}  {% include sections/browser-tweaks.html %}  {% include sections/email-providers.html %} {% include sections/email-clients.html %} {% include sections/email-alternatives.html %}  {% include sections/search-engines.html %} {% include sections/instant-messenger.html %} {% include sections/voice-video-messenger.html %} {% include sections/file-sharing.html %} {% include sections/cloud-storage.html %} {% include sections/selfhosted-cloud.html %} {% include sections/hosting-provider.html %} {% include sections/file-sync.html %} {% include sections/password-managers.html %} {% include sections/calendar-contacts-sync.html %} {% include sections/file-encryption.html %} {% include sections/self-contained-networks.html %} {% include sections/social-networks.html %} {% include sections/dns.html %} {% include sections/notebooks.html %} {% include sections/paste-services.html %} {% include sections/productivity-tools.html %} {% include sections/operating-systems.html %} {% include sections/live-operating-systems.html %} {% include sections/mobile-operating-systems.html %} {% include sections/android-addons.html %} {% include sections/router-firmware.html %} {% include sections/windows10.html %}  {% include sections/privacy-resources.html %} {% include sections/participate.html %} ``` * aka the bodycontents of https://github.com/privacytoolsIO/privacytools.io/blob/44acee2ef479727013cfc7796dc8f65060f4cb1d/pages/old.html would be generated from the sitemap.xml and then become the /summary </details> <details><summary>this is just a way to make maintenance easier ... the difference is not enduser-visible</summary> But the difference would be, compared to /classic, that the new /summary page would primarily concentrate on the "top3 cards" and most of the detailed guides (e.g. about:config tweaks) would not be on /summary at all, only appearing on the /browsers subpage itself. You can also get the same effect "manually" by hand-creating /summary and hand-updating it. Which might be less work than writing a bit of XSL, and would certainly be easier to update perhaps? But no, it definitely makes sense, if you have sitemap.xml, to use that to generate a human-readable /sitemap (or if you prefer /summary as the name). Dunno whether @libBletchley was suggesting an XSLT implementation approach when they recommended 'sitemap' as a name but that was immediately what came to *my* mind anyways Doesn't matter to the *enduser* aka the readership, whether you want to generate /summary from sitemap+xsl, or hand-compose the contents of /summary ... and indeed, doesn't matter whether you want to call it /summary as opposed to /sitemap since they both get the point across. But since you were trying to make the classic-one-big-page-layout obsolete, I figured you would be interested in auto-generating the /summary ? Definitely up to you though :-) Like I say, the readership won't see any difference, and I am only suggesting a pathway that *might* reduce maintenance-burden... depends on how wildly you envision the /summary contents diverging from the sitemap.xml leafnodes, as to whether that hypothetical burden-reduction would materialize. </details> > ...that [issue] should probably be made. I was imagining removing stuff from the summary like "Our VPN Provider Criteria", "What is a warrant canary?" Yes, agreed on both. For the first thing, I create #896 with some strikethru to indicate what I think can be elided on the summary-page, including most of what you wanted zapped

This repo is archived. You cannot comment on issues.