redoing our website is one thing — how this is taken up by the web as whole is another. Most people nowadays use search engines like Google to find information on the web.
Therefore it is important to see what happens if somebody googles „GNUstep“. I did so and here are some results and conclusions.
For that purpose I include some screenshots in my mail. I know this is usually not recommended but I want to explain my points using those.
At first, we’re doing not so bad overall, our (GitHub-hosted) website is hit #1!
I think that is mainly up to the reason that GitHub is a well known organization but also that this version of our website uses HTTPS!
Then the wikipedia site follows, which is also not bad.
Now that „People also ask“ section follows.
To answer those questions should be an important part of our web presence, especially „What is GNUstep used for?“ seems to be an important question which is unclear to a lot of folks out there.
Then „How to install GNUstep?“ is a question that comes up again and again. Obviously because it is not addressed well or clear enough on our website or the instructions differ to much in different places I guess.
On the right side of the Google page there is an info-box with a summarization of the Wikipedia contents. So far, so good. But what immediately hits me here is the part:
"Stable release: make 2.9.0, base 1.28.0, gui 0.29.0, back 0.29.0 / May 6, 2021; 3 years ago“
This is very bad! It makes the project look like it was dead, „3 years ago“! Didn’t we announce our latest release, which was not so long ago, properly?
Also it says: „Preview release: only in the SVN software repository“ which is simply not true, we stopped using SVN quite a time ago. Also this makes us look old-fashioned.
Now let’s talk about the rest of the Google page:
it finds our GitHub repo, o.k. but this hit should be further up on the page. I don’t know what can be done about this since I am not a SEO-Expert. But from what I heard more good links to the repo would help here, maybe also improvements to the README.mds in those repos.
The GNUstep Wiki is a work in progress, so not to bad it is still listed on the first page in Google.
Now some images follow. From Wikipedia and from our website. All are screenshots of GNUstep. Despite some people saying differently, good screenshots on our website are important! Also not only „NeXT-looking“ ones but some with modern themes.
The last part of the Google page shows a YouTube Video of GNUstep, https://www.youtube.com/watch?v=UiimELyGnC4 (which I did not watch yet), but wasn’t produced by us and seems to be about a GS-desktop, so there is demand for such a thing. But this is another discussion.
Lastly, the „Related searches“ section follows. This should give us an idea of what is searched for in relation to GNUstep: At first „GNUstep download“: people seems unable to find our download page. Then some searches in relation to different Linux distros but also „GNUstep Windows“ seems to be an important topic.
Not to forget about „GNUstep Wayland“ and „GNUstep Swift“, there seems to be enough interest so that Google put both into this section.
So, that’s it for today, I hope I could provide some insights an directions for our website.
Have a nice day and kind regards,
Lars
Am 25.07.2024 um 21:33 schrieb Damianos Sidiropoulos <damianos.bouzouki@gmail.com>:One more thought I forgot to add in the last message.
One of the reasons I wanted to steer the web site discussions off of the mailing list is to keep discussion limited to the people actually putting in the work on the web site. I'm afraid that continuing web site design and implementation discussions in the mailing list sets up an environment where we're designing by committee which is NOT what we want to do.
Looking forward to seeing you on github.
Best regards,
DamianOn Thu, Jul 25, 2024 at 2:48 PM Damianos Sidiropoulos <damianos.bouzouki@gmail.com> wrote:Hi guys.
Riccardo:
What we have done so far is to make some issues on the github repo. I suspect that might be the most neutral place to discuss ideas. It also has the added benefit of existing in the same location as the work being done.
On a higher level though, what I would propose for the web site in terms of process is to start with wireframes. Low fidelity sketches of how the content would be organized. It will also communicate what the general feel of the site will be.
I am making these wireframes in a new open source design tool called penpot. I can share these designs as progress is being made and even have the facility to do prototypes. That way we can have interactive illustrations of what we want without writing any code or disrupting the current web site that is live.
I have a couple of preliminary drafts started for the documentation area as well as the front page of the web site. The general approach is to have the documentation area contain the generated API docs as well as tutorials, and the rest of the site is pretty much just trying to sell developers on trying to make things with GNUstep. Put another way, developers go to the documentation area to get work done and new visitors can browse the rest of the site.
Here is a link to the current wireframes. You can switch between drafts on the top left side of the page.
https://design.penpot.app/#/view/352e9fc6-6a46-8154-8004-a926b6ec226e?page-id=c0408244-7a2c-80cc-8004-a96ba2c16b70§ion=interactions&index=0&share-id=352e9fc6-6a46-8154-8004-a985d3e18db6
The repo itself has a new branch called "clean-slate". We can make new branches based on that one when the time comes to implement things. Notice the only thing that has happened so far is to provide a clean slate. There are issues setup for the various topics that need to be addressed. You can view them here...
https://github.com/gnustep/gnustep.github.io/issues
Lastly, as Greg has mentioned, there is no intention of just nuking all of the content wholesale. The idea is to salvage what makes sense and reorganize everything under one umbrella. Additionally, with the new site being based on a static site generator, anybody can simply write an article in markdown and make a pull request. We can pull in any relevant wiki content and then retire that area. The added benefit is that the entire site, both the build config and the markdown content is under version control at all times. There is no PHP involved anywhere and the simple HTML/CSS/JS can be deployed anywhere with next to no security concerns. Anyways, these are currently the intentions but we are still in the design phase. I strongly suggest we continue this discussion in the github issues section. Looking forward to your participationOn Thu, Jul 25, 2024 at 2:04 PM Gregory Casamento <greg.casamento@gmail.com> wrote:Riccardo,On Thu, Jul 25, 2024 at 11:46 AM Riccardo Mottola <riccardo.mottola@libero.it> wrote:Hi Greg,
I am sorry that nobody else chimed in and that you were a little bit
dismissive on certain points.My apologies, it was not my intention to be dismissive. I simply meant to say that certain approaches haven't worked for us in the past. I will attempt to elaborate further below.Let me bring them up again and rephrase them.
I think there are some valid ideas in Damianos an subsequent heated
discussion and I don't want to act unilaterally.I think that's good and understandable. As I have said on other occasions, the website is the domain of the project, not just of one individual.> I worry that nothing will change. I know you're busy. I think
> what's best is if we develop another site in parallel, independent of
> the existing site.
I worry instead of a big remake or something similar, I am for
evolutionary changes.I need to understand what you mean by "evolutionary changes." I also need to understand why you're against a re-thinking of the site from the ground up if you are, indeed, against that.Any problem already addressed (e.g. naming issue)
can be of immediate benefit. Also one change can show the next path
under another light. Isn't that the base behind agile or small subprojects?Absolutely. I don't think the intention is "blow up the world and start again" but I also think that by designing it from the ground up, we can then see what can be reused instead of re-designing it from within the constraints of the existing site.>
>
> 1) "Core Library" name. Possibly logo?
>
>
> Also, need clarification. You already said you're against the logo
> that includes the orca, but I am not sure that matters. It's actually
> my preferred logo since it was something that was discussed a while back.
I specify: Damianos wanted to identify the project with its framework.
Now, if our project is "GNUstep" like confirmed in 2) I think we need a
specific way to name our core libraries.Over the site we call things like "GNUstep Suite", "libraries", "core"
or "GNUstep" without further specificationOkay, I see what you mean. I think we can do that no problem.I was thinking to a name for that. I'd stick with "GNUstep Core" to
base+gui+back, but we could also decide to add a catchy name.. akin
"cocoa". But most beans are already taken :)Cacao? Another way of saying Cocoa, actually it's the original spelling Cocoa is a product of consonantal shift over centuries (whole other discussion). But yes, core, is likely where it should be. My only concern with that is that Apple uses it for it's "CoreFoundation", "CoreText", blah blah. So people might confuse OUR core for their core if they are coming over from the mac, so we need to choose carefully.As for a logo, I'd suggest something specific to "GNUstep Core" to make
it visually recongizable. I was not suggesting to use our mascot and
change the GNUstep logo of the project.Ah! Okay. I wasn't clear on this in the original email when I read it. Makes sense.E.g a "folder" or a "library" with the GS logo. Or something else to
represent "core". It would be just of visual use in the website or wiki.
Then think if we want a name for the remaining other libraries
Okay> 2) Project name
>
>
> GNUstep. :) If you guys think it should be changed, fine, but I don't
> think that would work.
Agree. We could have called it like "GNUstep.org", or a specific
capitalization... no problem. Let's just rename the library. It is my
preferred line.
So GNUstep + Logo standard remain for the project. No big deal. I too
prefer to maintain logo & name the same for the project.Indeed... as you know I love the one with the orca, but yes. :)
>
> 3) "GNUstep name usage"
>
>
> Sorry, I am not sure that the idea of how the GNUstep name will be
> used ever came up or is in question. I do believe that WindowMaker is
> a very large source of confusion. So, for clarification, what are you
> referring to here?
I was not referring to WindowMaker, which is a source of confusion
because people are just lazy. Actually, it would be interesting to work
with them more again.Very true. The integration done by some of the other projects GSDE and others is VERY interesting.In this specific case, both sites state and even cross-link the
respective pages saying "we are not a windowmanager" and "we are not
GNUstep" :) I extra took care.I know... this is a stumbling block for most. I posted on a recent review of X11 on YouTube. The guy doing the review mentioned GNUstep so I thanked him for the mention and added a little information. I immediately got the response "Oh yes, I used to use GNUstep as my main Window manager for years". I was like *facepalm*... I explained and people got it. It's a process for sure.I was referring to projects, apps, desktops, distributions and other
things which use and refer to us with GNUstep.
Example: there exist(ed) the "GNUstep Live CD". They way it was labeled,
worded and distributed it appeared as an official CD and so the way
packages were chosen, styled, would "represent us". That is untrue and
can be misleading.Yep, this is a PROBLEM. Either that they represent us or that we endorse them or that, worse, WE were the ones who did it.On the other hand, these initiatives do bring us exposure and are
interesting, so I do not want to suffocate them or start putting
legalese "waivers" like "not officially endorsed".
I hope I expressed the concern... share your thoughts.Ahhhh.. I think we need to make it clear that people should check with us before calling something "The GNUstep Live CD" etc etc. Obviously we don't need to make this a "legal" thing just a "courtesy" thing. Given that the GNUstep Live CD is something that gets referenced a lot and wasn't even discussed with the group until it was released was, frankly, a bit shocking but because of it's name we get any credit OR blame that comes with it. Not really fair on either side.
> 4) relation to other Desktop environments and the way we "quote" them
> and how they can quote GNUstep
>
> Given that we are EXPLICITLY not a Desktop Environment, we should have
> links to them.
We have a links to them, of course. Also they are or can be described in
the Wiki. I changed the Website so that they are not on the homepage and
are presented more or less "equally"..
But how can or should them refer to us? I see no issue e.g. with Etoile
or NEXTSPACE.
But GSDE, GNUstep Desktop Environment, could be... since it sounds
"official".Yes, understood. We should discuss that with Sergii.I don't want to start a war now, just raising the flag. E.g. we could
think of asking certain "requirements" or a different, name, I have no
idea, just want you guys (and Greg) to think about it.
>
>
> I already have a couple of people on the discord (namely Ethan and
> Damian) discussing documentation. You should join.
> https://discord.gg/M2REKrD5
As expressed privately, I prefer not to use discord for FOSS activity,
it is discouraged and I agree. I no longer have an account on it.
I think for most topics it is good to have an archive, so email is good.Email is good if you want to get direction or some idea of what other people are doing and go off on your own. That doesn't really work here. :). I, personally, used to love IRC because we could have live discussions and feedback.Also, with different timezones and working days, it may take some time
for people to reply. So I wait for some time to reply.
If there are no answers I will draw conclusions. Usually it can be
interpreted, "I'm fine, I don't care, go ahead".
This is true... but not quite good enough. I suggest you email damian, you have his contact, and you guys can start discussing. And maybe even agree on a way to collaborate live, like you and I do on skype sometimes.>
> TBH, I think the wiki needs to be reduced. Right now it is somewhat
> redundant as some of the pages on the wiki have the same content as
> the pages on the main website. The wiki should be reserved for
> tutorials and other information.
I know that, it has a historical reason: lots of stuff was done on the
Wiki but not on the website. Then the Wiki went R/O.
True. As discussed previously... I'm going to review it like I am a newbie. :) Difficult for me I know, but I'll muddle through.The Wiki is a good collaborative place where also non-technical people
can contribute and generate content, which can be carried over to the
website (I did so several times). The Wiki then needs to be cleaned up
or minimized, we shall catch up on that activity and maybe define a
process to that. E.g. a section to review or "slated for removal".
Also there are some administrative issues, I'll contact you and Ivan
privately about that.
> 5) update and "describe" the library presentation (after 1) for obvious
>
> reasons shown here:
> https://www.gnustep.org/developers/map.html
>
>
> I think that map still makes a lot of sense. Is there a way we can
> generate some of this information as part of the documentation?
Not that I know, that content is more a "presentation" of the
architecture, not intrinsic in the classes.
That is exactly the kind of content we miss and need to enrich.
The map still makes a lot of sense, but do you agree that with some text
it would make it even more? With some text and references it would be a
great guide for developers.
Oh, sure. With more text and references, it would be very nice.>
> 7) Work with Richard on links to "unframe" frames of Reference
> documentation and study a way to navigate it within the site. Just a
> first step to clean this up.
>
>
> One thing that might be interesting here is to make it possible for
> autogsdoc to generate something other than HTML or to make it possible
> for it to avoid using some of the older tags which are not addressable
> by CSS.
I think we should have a work chain to generate a a PDF, so some people
can just download it and move around. Often more convenient.
A lot of ideas which are on my discussion plan with Richard, but major
work was done to actually generate correct pages (again!).Given that the tool outputs XML and then that XML is translated to HTML, we can use an XSLT transform to create any output format we like. I still think we need to FIX the HTML that is in there. We need to get rid of <font>, <frame>, and a few other deprecated tags that can't be addressed by CSS and make it impossible to improve the look of the documentation. The existing documentation is not consistent with the look of our website and so it stands out like a sore thumb. At the same time I think we can make it possible for older browsers to handle it so long as we find a decent set of tags that newer browsers support and that older browsers can use.With this we can parse it into anything we want. :)My attempts to style CSS failed miserably, I know others had more
success. I don't want to encumber offline versions, there are many pain
points in something apparently simple.Not your fault. It's the HTML that is generated.But one is: there are a lot of methods without description... so instead
of thinking of a "classy presentation" we should think also about the
content.
We seriously need to think about BOTH, ideally. :)Riccardo
--Yours, GCGregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron