On 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