Re: WebSite: navigation to bug reporting

2024-03-09 Thread lars.sonchocky-helld...@hamburg.de
Hi Riccardo,

thanks for your response. If I can help somewhere, please let me know.

> Am 10.03.2024 um 00:07 schrieb Riccardo Mottola :
> 
> Hi,
> 
> lars.sonchocky-helld...@hamburg.de wrote:
>> My opinion to, to long, unstructured texts are a bad thing (in Germany we 
>> say „Bleiwüste“ to this). But hidden stuff is also not the best. The most 
>> important things should be visible at a glance.
> 
> To be honest, it has some structurem but I get your point and I agree. 
> Especially the home page should be more a list of pointes. Yet it has grown 
> into an anticipation of lots of (repeated) things because there is the urge 
> of having everything upfront... like having it "first click" is best. However 
> at the end there are a lof of "click links". I share you approach of having 
> references, but I will try to move some of the text "down one level". To do 
> that, however, I need to reorganize the second-level pages a bit too, to 
> avoid repetition, which is boring. I need to split some pages too.
> I will work on it gradually to have everything "usable".
> 
> I think that once most of the brokeness is fixed, we can switch sites. These 
> are more presentation details that can be continued to be solved later on.
> 
> Riccardo

Kind regards,

Lars


Re: WebSite: navigation to bug reporting

2024-03-09 Thread Riccardo Mottola

Hi,

lars.sonchocky-helld...@hamburg.de wrote:

My opinion to, to long, unstructured texts are a bad thing (in Germany we say 
„Bleiwüste“ to this). But hidden stuff is also not the best. The most important 
things should be visible at a glance.


To be honest, it has some structurem but I get your point and I agree. 
Especially the home page should be more a list of pointes. Yet it has 
grown into an anticipation of lots of (repeated) things because there is 
the urge of having everything upfront... like having it "first click" is 
best. However at the end there are a lof of "click links". I share you 
approach of having references, but I will try to move some of the text 
"down one level". To do that, however, I need to reorganize the 
second-level pages a bit too, to avoid repetition, which is boring. I 
need to split some pages too.

I will work on it gradually to have everything "usable".

I think that once most of the brokeness is fixed, we can switch sites. 
These are more presentation details that can be continued to be solved 
later on.


Riccardo



Re: WebSite: navigation to bug reporting

2024-03-09 Thread Riccardo Mottola

Hi,

while simplifying some other elements on the home page (it got indeed 
crowded with time, with the urge to put everything on "the first click" 
and thus making a big lump of even repeated stuff) I took another attempt.


Riccardo Mottola wrote:
thanks for your opinion. "External" had a meaning year ago, when the 
project was on savannah and differently organized, most links there 
were "outside".


What do you think of moving the link to the github project under the 
developers menu - since it is something which interest more that kind 
of person and then renaming external to something else?
Just "More" or "Resources" could be a catch-all... 


I just called the menu "More" but also placed it last.
So you find in order:
-> Experience (mostly for users)
-> Developers
-> Support
-> More stuff that didn't fit there and now are really convenience 
link to GitHub and the Wiki.


I'll let it settle in a little bit.

Riccardo



Re: WebSite: navigation to bug reporting

2024-02-22 Thread lars.sonchocky-helld...@hamburg.de
Hi Riccardo,

> Am 22.02.2024 um 12:57 schrieb Riccardo Mottola :
> 
> Hi Lars,
> 
> 
> lars.sonchocky-helld...@hamburg.de wrote:
>> Some initial remarks first: I appreciate the effort you’re making to get us 
>> a better website. But I think before we lose ourselves in details of the 
>> menu structure, we should think about which audience we want to carter.
>> 
> 
> No, I don't want to stir up that question again. I made precise questions to 
> get answer about them, it was intentional.
> So, sorry, I will reply only to certain parts of your email, apologies in 
> advance. I did intentionally restrict the topic.
> 
>> Is it developers? Is it users? Is it both? Is it something to be discussed?
> 
> For me it is clear that we cater both... and I prefer not re-discussing this 
> to death again.
> The alternative would be to create two sites, but it would be worse in my 
> opinion, for what I will explain below.

If that is clear and everybody agrees, fine for me as well. Although I like to 
know if we have an „official“ position on this. I remember that in former times 
we said, that we are only a development environment. Perhaps I have missed a 
change here. What does our maintainer say? Greg?

> 
> Also, for this reason, parallels to GTK and GNOME have a limit, because they 
> have the two-site approach.

I am for just one site which caters both. But then again it would be possible 
to have a hybrid approach, where just gnustep.org is a landing page and two 
„sub sites“, let's say users.gnustep.org (or experience.gnustep.org if you 
prefer) and developers.gnustep.org which are also cross linked. While 
developers are most likely also users „dog feeding“ their own stuff, a sub site 
for users would be a good thing to have IMHO, since user have different needs 
than developers.

> 
>> I had a look and it looks improved compared to the current version at 
>> https://gnustep.github.io/ But I would refrain from renaming the menus „For 
>> Users“ and „For Developers“ to „Experience“ and just „Developers“.
> 
> Actually, it is the original wording which existed for years. I don't like 
> "For xxx" and it is a recent change I did not import back.
> While "Experience" and "Developers" is imperfect, "For Developers and "For 
> Users" always irritated me, I don't like menus with "For" and also strikes a 
> too tight line.
> 
>> 
>> „Experience“ is such a mushy word, it can mean everything and nothing at the 
>> same time, but definitely nothing I would click on. Also, if we want to 
>> carter to both users ands developers a the same time, I wouldn’t „hide“ this 
>> fact in such small menus which are easily overlooked but make it way more 
>> prominent.
> 
> It may be mushy, but it is definitely more correct than "For Users". The 
> idea, is that there you find information to "Use" GNUstep and also 
> information about the project. Something summed up with "Experience" (word 
> which has been in use by a dozen of years in the site, much before my 
> redesign).
> A "normal" end-user might not be interested in the developer section, but a 
> developer should be interested in the experience section.
> A developer should be informed about the project scope, applications, design, 
> etc.
> Like two levels, the first is only for the end-user, but the second builds on 
> the first level.
> 
> Perhaps, the wrong menu name is actually "Developers".. maybe more a word in 
> line with "Development".

Hence the „for Developers“ which is meant as an abbreviation of „GNUstep for 
Developers“. Just „Development“ could be mistaken of development of GNUstep 
itself (although developers for GNUstep itself are needed as much as 
Application developers).

> 
> 
> 
>> 
>> While I understand what you want to express with „External“ I think it is 
>> totally unclear what it means in this context. External what? Maybe use 
>> „External Resources“. Also, I think it is completely irrelevant to the user 
>> whether those stuff listed there is external to the website, it is not 
>> „external“ to the project.
> 
> They are not really external resources... and names should be short too.
> It contains references to various part of the project, but also to "external 
> to gnustep.org" since other projects use gnustep, but are not "gnustep.org"
> 
> I said that "External" is not meaningful nowadays. Essentially it is really 
> "More" or "Misc" but I hate to admit that.
> I don't want to split up things further

While those desktop environments are really somewhat separate from GNUstep (I 
wish they weren’t or we should at least have some sort of „reference 
implementation“), other things like the GitHub repo or the bugs section aren’t 
„external“. Maybe „Related“ or „related to GNUstep“ is a good wording here …

> 
>> 
>> „encouraging discovery“ doesn’t work if you ask me, our website shouldn’t be 
>> an adventure game. Instead this mostly leads to visitors leaving the page.
> 
> You interpret it wrong. Most site I use daily go this route, maybe my 

Re: WebSite: navigation to bug reporting

2024-02-22 Thread Riccardo Mottola

Hi,

Riccardo Mottola wrote:
I think it is not a big evil to have 4 menus, we have decent screens 
and it encourages browsing items (and thus encourages discovery, not 
needing to put everything in the text). 


minor update: I tested the 4 menu navigation on an iPad and it continues 
to work well, so while I had some concerns, it is responsive enough.

Even on a small phone it stays usable.

So the problem evenually remains in the correct wording and organization.


Riccardo



Re: WebSite: navigation to bug reporting

2024-02-22 Thread Riccardo Mottola

Hi Lars,


lars.sonchocky-helld...@hamburg.de wrote:
Some initial remarks first: I appreciate the effort you’re making to 
get us a better website. But I think before we lose ourselves in 
details of the menu structure, we should think about which audience we 
want to carter.




No, I don't want to stir up that question again. I made precise 
questions to get answer about them, it was intentional.
So, sorry, I will reply only to certain parts of your email, apologies 
in advance. I did intentionally restrict the topic.


Is it developers? Is it users? Is it both? Is it something to be 
discussed?


For me it is clear that we cater both... and I prefer not re-discussing 
this to death again.
The alternative would be to create two sites, but it would be worse in 
my opinion, for what I will explain below.


Also, for this reason, parallels to GTK and GNOME have a limit, because 
they have the two-site approach.


I had a look and it looks improved compared to the current version at 
https://gnustep.github.io/ But I would refrain from renaming the menus 
„For Users“ and „For Developers“ to „Experience“ and just „Developers“.


Actually, it is the original wording which existed for years. I don't 
like "For xxx" and it is a recent change I did not import back.
While "Experience" and "Developers" is imperfect, "For Developers and 
"For Users" always irritated me, I don't like menus with "For" and also 
strikes a too tight line.




„Experience“ is such a mushy word, it can mean everything and nothing 
at the same time, but definitely nothing I would click on. Also, if we 
want to carter to both users ands developers a the same time, I 
wouldn’t „hide“ this fact in such small menus which are easily 
overlooked but make it way more prominent.


It may be mushy, but it is definitely more correct than "For Users". The 
idea, is that there you find information to "Use" GNUstep and also 
information about the project. Something summed up with "Experience" 
(word which has been in use by a dozen of years in the site, much before 
my redesign).
A "normal" end-user might not be interested in the developer section, 
but a developer should be interested in the experience section.
A developer should be informed about the project scope, applications, 
design, etc.
Like two levels, the first is only for the end-user, but the second 
builds on the first level.


Perhaps, the wrong menu name is actually "Developers".. maybe more a 
word in line with "Development".






While I understand what you want to express with „External“ I think it 
is totally unclear what it means in this context. External what? Maybe 
use „External Resources“. Also, I think it is completely irrelevant to 
the user whether those stuff listed there is external to the website, 
it is not „external“ to the project.


They are not really external resources... and names should be short too.
It contains references to various part of the project, but also to 
"external to gnustep.org" since other projects use gnustep, but are not 
"gnustep.org"


I said that "External" is not meaningful nowadays. Essentially it is 
really "More" or "Misc" but I hate to admit that.

I don't want to split up things further



„encouraging discovery“ doesn’t work if you ask me, our website 
shouldn’t be an adventure game. Instead this mostly leads to visitors 
leaving the page.


You interpret it wrong. Most site I use daily go this route, maybe my 
wording did convey the wrong concept to you.
Instead of reading long texts to find something, you look for menus or 
navigation items.
Many sites are done this way, also professional stuff I use for work. 
You find in the menu things like payments, downloads and such.

It just feels natural and people are accustomed to explore, click around.
Like you don't read a manual when using an App, just... "discover it" 
because things have expected names, places, icons...


It can be taken to the extreme like in www.netbsd.org, where you access 
everything from the navigation menu at left.
Also the gnome.org site you cited is a comprompise between. E.g. you 
find the "Donate" only in the bar, not in the text, as the technologies 
used are just one-click in the menu, not in the text.





I hope you consider my critique not as harsh or unfriendly. I am 
trying to find the weaknesses in our current approach towards a good 
solution for GNUstep as a whole.


Nothing harsh.. it happens that we disagree on certain things and 
perhaps just misunderstood on others. But there is alot of personal 
experience and taste involved.




If you don’t like this, please let me know!


No problem with discussion, I read and evaluate. But you did not 
actually give answers to some of my questions. That's all :)


Peace,

Riccardo



Re: WebSite: navigation to bug reporting

2024-02-21 Thread lars.sonchocky-helld...@hamburg.de
Hi Riccardo and others,


Some initial remarks first: I appreciate the effort you’re making to get us a 
better website. But I think before we lose ourselves in details of the menu 
structure, we should think about which audience we want to carter.

Is it developers? Is it users? Is it both? Is it something to be discussed?

And I think there are examples again from which to learn. Take for instance our 
„competitors“ GTK/GNOME or QT/KDE. Both consist out of a Framework/API and a 
desktop environment.

Let’s look at GTK/GNOME first (also because QT is a commercial venue which in 
turn has some other interests too) 

Clearly, their framework GTK carters to developers: have a look at 
https://www.gtk.org/ : their site is concise and clearly structured, they have 
a claim „Create apps that users just love“. Their website consists out of a 
„head“-section in black (claim, one sentence introduction, „Learn GTK“-Button 
and Downloads with versions). Then more detail sections follow: „Work with the 
language of your choice“, „Apps built with GTK“, „A feature-rich development 
tool“ and so on, you get the idea.

Then there is their user website: https://www.gnome.org/ which is also clear 
and concise but for a completely different audience. Compare both and you’ll 
see. 

The same can be said about https://kde.org/ (which forwarded me to a localized 
version: https://kde.org/de/ (nice, but not necessary))

> Am 20.02.2024 um 21:51 schrieb Riccardo Mottola :
> 
> Hi,
> 
> H. Nikolaus Schaller wrote:
>> Indeed. Placing a prominent "Bug" button in front will carry the message 
>> that the Software is "buggy"... So it may have an unintended negative effect.
>> 
>> But "Help"/"Support" is much better, IMHO.
> 
> You have a point and I agree. I made a new proposal, I pushed it to the first 
> page only for now, as a test (we don't have unfortunately a test website 
> where to test a branch). So check http://home.gnustep.org

I had a look and it looks improved compared to the current version at 
https://gnustep.github.io/ But I would refrain from renaming the menus „For 
Users“ and „For Developers“ to „Experience“ and just „Developers“.

„Experience“ is such a mushy word, it can mean everything and nothing at the 
same time, but definitely nothing I would click on. Also, if we want to carter 
to both users ands developers a the same time, I wouldn’t „hide“ this fact in 
such small menus which are easily overlooked but make it way more prominent.

Never forget, we are „insiders“ who know GNUstep like the back of our hand. 
Others (our audience) don’t. What is clear to us, needs explanation for them.

> 
> I found we had some similar content in different places, I rationalized it to 
> one place and created a new menu "Support" which has a link to the Mailing 
> List and to Bug reporting.
> Thus now "External" Is really just a menu to various resources.

While I understand what you want to express with „External“ I think it is 
totally unclear what it means in this context. External what? Maybe use 
„External Resources“. Also, I think it is completely irrelevant to the user 
whether those stuff listed there is external to the website, it is not 
„external“ to the project.

> 
> I think it is not a big evil to have 4 menus, we have decent screens and it 
> encourages browsing items (and thus encourages discovery, not needing to put 
> everything in the text).

„encouraging discovery“ doesn’t work if you ask me, our website shouldn’t be an 
adventure game. Instead this mostly leads to visitors leaving the page.

> 
> What do you think?
> 
> We could also think of moving the items in "External" with some forcing to 
> the rest of menus.
> * GitHub project: under developers
> * Wiki : e.g. to support or experience
> * Related Sites: under Experience
> * Donations: under support (it is support... for us)
> 
> 
> Awaiting your comments before propagating the change.

I hope you consider my critique not as harsh or unfriendly. I am trying to find 
the weaknesses in our current approach towards a good solution for GNUstep as a 
whole.

If you don’t like this, please let me know!

> 
> Riccardo

best regards,

Lars




Re: WebSite: navigation to bug reporting

2024-02-20 Thread Riccardo Mottola

Hi,

H. Nikolaus Schaller wrote:

Indeed. Placing a prominent "Bug" button in front will carry the message that the 
Software is "buggy"... So it may have an unintended negative effect.

But "Help"/"Support" is much better, IMHO.


You have a point and I agree. I made a new proposal, I pushed it to the 
first page only for now, as a test (we don't have unfortunately a test 
website where to test a branch). So check http://home.gnustep.org


I found we had some similar content in different places, I rationalized 
it to one place and created a new menu "Support" which has a link to the 
Mailing List and to Bug reporting.

Thus now "External" Is really just a menu to various resources.

I think it is not a big evil to have 4 menus, we have decent screens and 
it encourages browsing items (and thus encourages discovery, not needing 
to put everything in the text).


What do you think?

We could also think of moving the items in "External" with some forcing 
to the rest of menus.

* GitHub project: under developers
* Wiki : e.g. to support or experience
* Related Sites: under Experience
* Donations: under support (it is support... for us)


Awaiting your comments before propagating the change.

Riccardo



Re: WebSite: navigation to bug reporting

2024-02-19 Thread H. Nikolaus Schaller



> Am 19.02.2024 um 12:11 schrieb Riccardo Mottola :
> 
> Hi,
> 
> Daniel Boyd wrote:
>> My vote is the "prominent place" option even though I admit it does detract 
>> somewhat from a clean aesthetic. But I think it's worth it.
> 
> You and Fred - opposite opinions.
> In my original design years aog, I put the bug prominent, then just before 
> our site crash, I started moving it into the menu, but never finished the 
> work.
> Now I want to clean things up.
> 
> 
>> 
>> By having it in a prominent location, the most direct effect is that it will 
>> be easier to find. I don't think that matters as much for developers, most 
>> of whom will explore the site thoroughly, so I'm thinking more of the impact 
>> on end users. End users may or may not be accustomed to reporting bugs and I 
>> think there is some value in giving them a subtle message that the project 
>> encourages bug reports. I think by having a link to the bug report page in 
>> their field of vision every time they are on a gnustep.org 
>>  page, you may end up with a higher percentage of users 
>> submitting bug reports.
> 
> Your reasoning has some truth. But consider some additional elements.
> The concept of "bug report" is something for more experienced users: of 
> course developers, but also "advanced" users and those should be able to look 
> for it in a menu... maybe they already know how to use github.
> A layman, instead, just needs "help", he has an issue, which might not even 
> be a bug. So a check in the docs or in the wiki for self-help, a post on the 
> Mailing Lists may be a prior step to take. More "support" or "help" than 
> directly a bug.

Indeed. Placing a prominent "Bug" button in front will carry the message that 
the Software is "buggy"... So it may have an unintended negative effect.

But "Help"/"Support" is much better, IMHO.

just my 2ct from marketing PoV,
Nikolaus




Re: WebSite: navigation to bug reporting

2024-02-19 Thread Riccardo Mottola

Hi Fred,

Fred Kiefer wrote:

I like the way you put it in the menu. The name „External“ is really a bit 
confusing, but at the moment I don’t have a better idea.


thanks for your opinion. "External" had a meaning year ago, when the 
project was on savannah and differently organized, most links there were 
"outside".


What do you think of moving the link to the github project under the 
developers menu - since it is something which interest more that kind of 
person and then renaming external to something else?

Just "More" or "Resources" could be a catch-all...

Riccardo



Re: WebSite: navigation to bug reporting

2024-02-19 Thread Riccardo Mottola

Hi,

Daniel Boyd wrote:
My vote is the "prominent place" option even though I admit it does 
detract somewhat from a clean aesthetic. But I think it's worth it.


You and Fred - opposite opinions.
In my original design years aog, I put the bug prominent, then just 
before our site crash, I started moving it into the menu, but never 
finished the work.

Now I want to clean things up.




By having it in a prominent location, the most direct effect is that 
it will be easier to find. I don't think that matters as much for 
developers, most of whom will explore the site thoroughly, so I'm 
thinking more of the impact on end users. End users may or may not be 
accustomed to reporting bugs and I think there is some value in giving 
them a subtle message that the project encourages bug reports. I think 
by having a link to the bug report page in their field of vision every 
time they are on a gnustep.org  page, you may end 
up with a higher percentage of users submitting bug reports.


Your reasoning has some truth. But consider some additional elements.
The concept of "bug report" is something for more experienced users: of 
course developers, but also "advanced" users and those should be able to 
look for it in a menu... maybe they already know how to use github.
A layman, instead, just needs "help", he has an issue, which might not 
even be a bug. So a check in the docs or in the wiki for self-help, a 
post on the Mailing Lists may be a prior step to take. More "support" or 
"help" than directly a bug.


Riccardo



Re: WebSite: navigation to bug reporting

2024-02-16 Thread Daniel Boyd

My vote is the "prominent place" option even though I admit it does detract somewhat from a clean aesthetic. But I 
think it's worth it. By having it in a prominent location, the most direct effect is that it will be easier to find. I don't 
think that matters as much for developers, most of whom will explore the site thoroughly, so I'm thinking more of the impact 
on end users. End users may or may not be accustomed to reporting bugs and I think there is some value in giving them a 
subtle message that the project encourages bug reports. I think by having a link to the bug report page in their field of 
vision every time they are on a gnustep.org page, you may end up with a higher percentage of users submitting bug reports. On 
Feb 16, 2024, at 11:22 AM, Fred Kiefer  wrote: I like the way you put it in the menu. The name 
„External“ is really a bit confusing, but at the moment I don’t have a better idea. Cheers, Fred Am 16.02.2024 um 15:38 
schrieb Riccardo Mottola : Hi, I want to uniform the bug reporting on our website. 
Originally, we had a single page on savannah for all projects. I found this better than the current situation of github, were 
every sub-project has its own issue tracker. This makes reclassifying a bug impossible and also confuse newcomers. But is 
what it is, I created a single page which should help as a collector and points to te trackers of the most common projects. 
See it here: https://home.gnustep.org/bugs.html We also had a wiki page: https://mediawiki.gnustep.org/index.php/Report_Bugs 
But the wiki was not available for a long time and also, now it needs to be promoted. It would be best if bugs.gnuste.org 
could point to https://home.gnustep.org/bugs.html eventually. But question: where to put the navigation? Under a 
"menu" like you can see here: https://home.gnustep.org/index.html (name of menu and structure are another topic, 
current name is "External") Or on a separate item, maybe even in a prominent place like at right, as here: 
https://home.gnustep.org/jigs/index.html Both have pro, say yours. Riccardo

Re: WebSite: navigation to bug reporting

2024-02-16 Thread Fred Kiefer
I like the way you put it in the menu. The name „External“ is really a bit 
confusing, but at the moment I don’t have a better idea.

Cheers,
Fred

> Am 16.02.2024 um 15:38 schrieb Riccardo Mottola :
> 
> Hi,
> 
> I want to uniform the bug reporting on our website.
> Originally, we had a single page on savannah for all projects. I found this 
> better than the current situation of github, were every sub-project has its 
> own issue tracker. This makes reclassifying a bug impossible and also confuse 
> newcomers.
> 
> But is what it is, I created a single page which should help as a collector 
> and points to te trackers of the most common projects.
> See it here: https://home.gnustep.org/bugs.html
> 
> We also had a wiki page: https://mediawiki.gnustep.org/index.php/Report_Bugs
> But the wiki was not available for a long time and also, now it needs to be 
> promoted.
> 
> It would be best if bugs.gnuste.org could point to 
> https://home.gnustep.org/bugs.html eventually.
> 
> But question: where to put the navigation?
> Under a "menu" like you can see here: https://home.gnustep.org/index.html
> (name of menu and structure are another topic, current name is "External")
> 
> Or on a separate item, maybe even in a prominent place like at right, as 
> here: https://home.gnustep.org/jigs/index.html
> 
> Both have pro,  say yours.
> 
> Riccardo
> 




WebSite: navigation to bug reporting

2024-02-16 Thread Riccardo Mottola

Hi,

I want to uniform the bug reporting on our website.
Originally, we had a single page on savannah for all projects. I found 
this better than the current situation of github, were every sub-project 
has its own issue tracker. This makes reclassifying a bug impossible and 
also confuse newcomers.


But is what it is, I created a single page which should help as a 
collector and points to te trackers of the most common projects.

See it here: https://home.gnustep.org/bugs.html

We also had a wiki page: https://mediawiki.gnustep.org/index.php/Report_Bugs
But the wiki was not available for a long time and also, now it needs to 
be promoted.


It would be best if bugs.gnuste.org could point to 
https://home.gnustep.org/bugs.html eventually.


But question: where to put the navigation?
Under a "menu" like you can see here: https://home.gnustep.org/index.html
(name of menu and structure are another topic, current name is "External")

Or on a separate item, maybe even in a prominent place like at right, as 
here: https://home.gnustep.org/jigs/index.html


Both have pro,  say yours.

Riccardo