search

gnustep / gnustep.github.io

GNUstep website hosted on GitHub
7 stars 7 forks source link

Site Map #14

Open dszidi opened 1 month ago

dszidi commented 1 month ago

Figure out the general architecture of the site. What areas should exist and decide on pages that live in them. After that is decided, the front page content will be easier to plan.

Pages

Social Media

EDIT: Tweaked area names and descriptions

dszidi commented 1 month ago

@gcasa Do you think there should be a languages section?

gcasa commented 1 month ago

@gcasa Do you think there should be a languages section?

Not at the moment. Currently neither libs-ruby nor libs-java work. Once they do then yes, I believe so.

ethanc8 commented 1 month ago

@gcasa Do you think there should be a languages section?

Not at the moment. Currently neither libs-ruby nor libs-java work. Once they do then yes, I believe so.

Oh, that's a bit unfortunate. The only actively maintained language bindings I know of is Objective-S. It's actually a pretty cool language binding. Additionally, I think that StepTalk Smalltak still works, but it's much less featureful than Objective-S. However, it's closer to ANSI Smalltalk than Objective-S is, and it has an interpreter rather than a compiler to x86 and ARM assembly like Objective-S has.

ethanc8 commented 1 month ago

  • Front Page

  • API Documentation (Consume html generated by AutoGSDoc)

  • IDE (Page dedicated to Project Center/Gorm that links to an online user guide )

  • Getting Started (Pages for setting up toolchains on different platforms)

  • Platforms (Separate pages for every supported platform you can build for eg. Mac/Windows/Linux/Android etc)

  • Case Studies (If there are any notable 3rd party apps that have been developed, we should interview the devs and showcase the app)

  • News (blog with any relevant news)

Should we have a tutorials section? Also, what about the manuals for the different tools? Most Python projects keep the manuals and API docs together, and heavily link between the two. Typically, the API docs are a section at the back of the manual, but they might also be intertwined together -- for example, if a library has multiple parts, it might be split into documentation for each part, where each part has manual pages and API docs in their own sections.

At least for GNUstep Make, the API docs I'm writing for it will be useful.

  • Getting Started (Pages for setting up toolchains on different platforms)

  • Platforms (Separate pages for every supported platform you can build for eg. Mac/Windows/Linux/Android etc)

These seem like they should be combined. Maybe we should just make a "Getting Started" button on the main page, that brings you to the first tutorial. That first tutorial would include a quick guide to setup, with links to more options and details which would be in the "Platforms" side. We might also want to rename "Platforms" to "Deployment", but I'm not sure. The configuration guide might end up on the "Platforms" section, which although it's quite related, isn't exactly ideal.

Maybe manuals, guides, and tutorials should be mixed together, they seem kinda similar. Alternatively, we could split them apart by each library/tool, but there are many tasks that would require multiple and would need a tutorial -- for example, a build-your-first-app tutorial would require Gorm.

dszidi commented 1 month ago

I have an initial draft where I've already made some changes to some of the names. Documentation will be a section that contains more than just the API docs. It should contain all the relevant tutorials and any other. There is a link in the wireframes ticket where you can see the most current version of the designs.

This is a screenshot of the sidebar navigation

image

If a visitor clicks on the API docs link then that section's sidebar will look like this...

image

I also made the top navigation for the overall site like this for now.

image
dszidi commented 1 month ago

I updated the first post to reflect the adjusted navigation

ethanc8 commented 1 month ago

I have an initial draft where I've already made some changes to some of the names. Documentation will be a section that contains more than just the API docs. It should contain all the relevant tutorials and any other. There is a link in the wireframes ticket where you can see the most current version of the designs.

This is a screenshot of the sidebar navigation

image

If a visitor clicks on the API docs link then that section's sidebar will look like this...

image

I also made the top navigation for the overall site like this for now.

image

This design will most likely require a much more involved Sphinx theme, rather than simply replacing the CSS for pydata-sphinx-theme. But it looks quite useful! Nice!

rmottola commented 1 month ago

Social Media

* Github

* Facebook

* Instagram

* X (aka Twitter)

* YouTube

* LinkedIn

I don't think "github" is social media, but it is the "main project page" so essentially the place where both users and developers interact when looking for issues, latest versions and download (for GH oriented people).

Up to now we didn't boldly link e.g. the GNUstep group on Facebook or the various X/Twitter efforts. We also have some blogs. However most of these are essentially "user maintained".

Are you suggesting we need all these channels or also interweave them with the website?

rmottola commented 1 month ago

Pages

* Front Page (The main pitch to get devs interested plus latest news)

* Documentation (Contains all relevant "getting started" tutorials, articles and api documentation)

* Tools (Page dedicated to Project Center/Gorm that links to an online user guide )

* Platforms (Page that advertises GNUstep's supported target platforms eg. Mac/Windows/Linux/Android/Custom etc)

* Case Studies (If there are any notable 3rd party apps that have been developed, we should interview the devs and showcase the app)

* News ** (blog with any relevant news. Should launch this after the YouTube channel has some content)

* Contribute (Page describing how developers can contribute code, documentation, issue tracking etc)

As I expressed myself on the mailing list, I sum up here: thee content topic are essentially the "developer" oriented part. I have the idea that GNUstep should present itself to both Users and Developers and convey a general picture of what can be achieved. Some section then are common to both aspects. E.g. both users and developers find bugs, so both are interested in issue tracking. Both need documentation, but the former is interested perhaps in just setup and configuration, the latter wants the API reference. Since he may use developer tools, also the other parts are interesting

dszidi commented 1 month ago

I don't think "github" is social media, but it is the "main project page" so essentially the place where both users and developers interact when looking for issues, latest versions and download (for GH oriented people).

Semantics here. It is technically not social media in the same way the others are but still it is a gathering place for developers. More importantly, we want easy access for visitors. It is also a pretty standard pattern for software project web sites to put a github logo somewhere that is easily accessible from any page on the site.

Up to now we didn't boldly link e.g. the GNUstep group on Facebook or the various X/Twitter efforts. We also have some blogs. However most of these are essentially "user maintained".

Are you suggesting we need all these channels or also interweave them with the website?

The thought was to use all these platforms to get news of site updates and announcements out to the public. This does not need to be a tedious thing. There is an Adobe Express service that makes all this trivial. (There is a free tier btw) A simple post can be crafted on the web interface and simultaneously launched to all the platforms at once. Even if nothing else ever got pushed out to these social media platforms other than announcements, it would be a huge improvement for outreach.