So I'll just start by quoting David;

david_edmundson wrote:OK so there was some consensus that we can do content and top-down stuff in parallel.

So. Content:

Priority is this page https://www.kde.org/workspaces/plasmadesktop/

it's the highest viewed page on kde.org (besides the front page) and it shows the wrong frickin' version of Plasma.

I need:
- text
- A list of features of Plasma to show off
- good screenshots of all the good bits
- text
- making it pretty

I made an etherpad for text: https://notes.kde.org/p/workspace_website

if people like writing, please help.
screenshots to a place on share.kde.org please.

Lets roll.

The first thing, obviously, is that what we do here will ultimately be injected into a dynamic system. So while we're working out the details on that system, we should take this as a design exercise to try determining what the end results will look like. It also works out that Plasma Desktop is a KDE flagship project, so just about anything that applies anywhere will apply to Plasma Desktop.

(Please crit&question everything I'm about to write BTW)

On the content itself and how the site is assembled, I've had two main ideas for how the site will be built on the front-end - so I'll give you my own vision as a whole before I get into the Plasma Desktop page itself;

I'd like to divide the website into 3 distinct 'areas' of content;

• End users / main site
• Developers
• Professionals & Administrators

Between each area content and structure will vary as appropriate. Each area would have a distinct look and colour scheme (Users get a light scheme, professional get a slate scheme, and developers get a blue scheme).

The end-user areas will be more focused on banner features and aesthetic pages. Essentially, these are pages built to "sell" the software they're looking at. Lots of imagery and less text on promotional pages, very simplified navigation structures for doing things like getting help. We'll also downplay jargon, and we won't advertise highly technical features. If you want to use Plasma or KDE applications as your daily driver, these pages show you what we have and how to use it, and why it's pleasurable.

Developer pages will be for both KDE developers and general coders. These pages may use light imagery on occasion in the form of icons and screenshots, but these won't be "press" pages. Developer areas will focus on developer news, documentation, guidelines, tech tech tech. If you want to build for, on, or with anything KDE these are the pages for it.

Lastly, professional and administrator pages. Generally these pages are made for people who need to get the most of the software, and for different projects this may mean different things. Information on how an IT administrator deploys Plasma Desktop across 200 computers requires is different than how a design firm can get the most out Krita for their 6 artist team, or a single artist looking to switch from Adobe. These pages will be a mix between what is seen on the relatively content-light user-pages vs the dense materials of the developer pages because they must do two things; convince professionals that the software is as amazing as it is - and also enable them to use it to capacity. Industry jargon will be fine here. Parts of these pages may have visual flair, but it will not make the majority of the content.

---

So, with all that it means we actually want *3* or so pages for Plasma Desktop. One will be the compliment to the current iteration, which is more end-user driven. The next will be a skeleton developers page which mostly links to existing documentation. The last one will be a professionals page which will, again, be mostly a skeleton page, albeit with maybe some name-dropping of major Plasma usage (Doesn't CERN use it? As well as some school boards?)

These pages will probably be pretty sparse, but when the dynamic CMS-driven content starts to land we'll quickly be able to flesh things out.

how does that sound?

do the developer and professional pages not conflict with the already existing solution on the xbases (community/techbase/userbase.kde.org)?

neverendingo wrote:do the developer and professional pages not conflict with the already existing solution on the xbases (community/techbase/userbase.kde.org)?

That's actually where I got the idea from. More/less it's my attempt to get everything tied together more closely as a method of using a central CMS a little more effectively. it doesn't mean we're getting rid of those pages, but we need a way of getting the content of those pages crosslinked and added more deeply into project pages in an immediately understandable way. Some articles might be replaced, some might not. I don't know quite how it will shake down - KDE.org has many moving parts.

As an example: Digikam! It can be found in all 3 bases... But they don't interact or link back to eachother, at least not in an obvious way which I able to find. If I was interested in Digikam and wanted to know everything about it - that's a near-impossible task for KDE.org because the content of Digikam is in 3 isolated wikis and an separate application entry. It also has its own separate website which helps... But we can and shouldn't expect that to be the norm. It is literally faster to Google Digikam 3 times than it is to navigate through KDE.org itself. You could argue it's just a case of going in and adding the links, but the fact we don't have any sort of standard mechanism to tie these pages together is terrible.

The website definitely needs to shift to a "project-oriented" mentality, because the current "silo" approach makes browsing the site a nightmare. Hopefully what I'd like to see is each project getting a small bundle of optional CMS-based systems (or external systems with integrated models - such as Phabricator). When browsing a project like Digikam, the Digikam pages (especially in the footers) would cross-link between the areas.

Wikis just aren't the best way to store *all* content. We're using wikis the same way other websites use a proper CMS... I'm seeing things like schedules in there, developer notes (in the userbase wikis), everything you could probably name. Wikis are great for articles, documentation - but we're making them do too much, and it's just a mess in there. The *base pages aren't going to go away, and if anything they'll just fall into their respective areas with some look'n'feel rollouts. Hopefully what I'd like to see is our CMS handle at lot of the really standard stuff in a much cleaner way, lighten the load for the wikis, and let them focus a bit better.

I guess it may make sense to say that these "areas" aren't specific sections in the site as much as they're specific sections in individual projects.