On 2015-12-22 16:05, Adam D. Ruppe wrote:

> The new logo design still struck me as the same brand when I first saw it.

It's the shape that you recognize (the D and the two moons). The rest is just extra.

-- 
/Jacob Carlborg

On 22.12.2015 16:01, Dmitry wrote:
> On Tuesday, 22 December 2015 at 13:38:48 UTC, Charles wrote:
[...]
>> To be fair, D's documentation uses a left-side menu, but it removes
>> the top level navigation (you have to press the logo).
> Yep, new design has _same_ solution.

No, the mock-up doesn't provide a library menu at all (it glances over the issue), and the hacked-together full preview provides a vertical library menu in addition to the horizontal main menu. Neither is the same as dropping the main menu completely, which is what the current dlang.org does.

On Tuesday, 22 December 2015 at 15:17:57 UTC, Adam D. Ruppe wrote:
> and a good web design should work in all these cases.
I agree. My message was that current design supports any size, but new design does not support widescreens.

On 22.12.2015 16:43, Dmitry wrote:
> I agree. My message was that current design supports any size, but new
> design does not support widescreens.

There's a point where claiming more horizontal space doesn't improve the usability of the site any more.

Yes, more stuff fits on one screen, but readability suffers when text lines get too long. And we have lots of short lines on dlang.org, so we don't get that much more stuff on the screen anyway. The only thing we really achieve is bad looks.

On 12/22/2015 02:19 AM, Jacob Carlborg wrote:
> On 2015-12-21 18:37, Andrei Alexandrescu wrote:
>
>> That's a large leap. I suggest using Ddoc instead of Sass compact CSS
>> files, see the existing instance at
>> https://github.com/D-Programming-Language/dlang.org/blob/master/css/cssmenu.css.dd.
>>
>>
>>
>> CoffeeScript sounds like a nice thing to add and is from what I've heard
>> reasonably stable.
>>
>> We can't make the site depend on dub at this time. There have been
>> situations in the past when dub wouldn't build and nobody was available
>> to work on it. At that time only the alternate documentation got broken,
>> but if the site depends on it we're looking at catastrophic failure.
>
> I have no interest in using Ddoc. If that's a requirement we can close
> down the redesign idea completely.

I was afraid you were going to say this. Looks like we're reaching an impasse again, so let me explain the situation from where I stand and kindly attempt to change your viewpoint a bit.

One simple matter of fact is that most work and maintenance on dlang.org (https://github.com/D-Programming-Language/dlang.org/graphs/contributors) is done by a handful of folks: Walter, myself, Kenji, Martin, Vladimir, followed by a long tail. Lately it's been Vladimir, Martin, and myself who did most maintenance work.

A consequence of that is when someone proposes a different technology for dlang.org, the proposal is really that Vladimir, Martin, and me become fluent in it. This is a very simple fact that I have had difficulty communicating. I've said several times that the only thing that would make e.g. vibe.d more used on dlang.org is the availability of people able and willing to help with it.

As far as I understand you are well versed in a variety of Web-related tools, and have your preferences in terms of tooling you use etc. That's totally cool. Also, my understanding is that you'd consider helping with the redesign but only as a one-off contribution; there'd be no implied commitment that you'd be available for solving various issues related to the technologies you propose. This makes things more difficult for everyone involved. What would help would be a bit more flexibility with the choices made and more convergence toward compromise. You can't come with a battery of large changes in a take it or leave it manner.


Thanks,

Andrei

On Tuesday, 22 December 2015 at 15:01:52 UTC, Dmitry wrote:
> On Tuesday, 22 December 2015 at 13:38:48 UTC, Charles wrote:
>> That's silliness, and not how percentages work at all. To suggest that 95% of people that go to dlang.org have widescreens because 95% of some other user base is nonsense.
> 1) Do you have statistics of dlang.org?

This is entirely my point. I don't, and I can't tell from your response that you do either.

> 2) Do you think that dlang.org statisitcs will be very different with world statistics? I don't think so.

Yes. I'd suspect the number of people using phones to visit a programming language website would be smaller than, say, Facebook. I have no way of telling though. Do you? It's better to not assume.

> 3) Do you think that % of 4:3 displays will not drop? In all world it decrease each month.

Websites need to be maintained just like anything else. That's the entire point of this thread.

> I used statistics from my professional sphere, but ok, lets try google any other.
> For example, http://www.w3schools.com/browsers/browsers_display.asp
> 1024x768  Jan 2015: 4%
> 1280x1024 Jan 2015: 7%
> 1366x768 33%
> 1920x1080 16%

They state right on the page that its only visitors of w3schools.com, so... people interested in learning web development.

> Other way. Check any shop. How many new monitors 4:3 (or 5:4) it have, and how many widescreen?
> Check, how many new 4:3 models have, for example, LG? One. Asus? No one. Any other company? Only a few, right? Trend is that % of 4:3 displays goes to be 0 soon.

Completely correct. Now, how many monitors support a vertical orientation? Just because its uncommon doesn't mean its not done.

>> Opinion. I agree with you, but why alienate anyone? It's not like narrow websites are unusable. They're just not your preference. For people like Ola, wide websites are legitimately unusable.
> I did not say that site must be only for widescreen. Keywords: Responsive Web Design.

Go ahead and Google that. I can almost guarantee you one of the first things you'll find is "Mobile First". Yeah, its still a big deal.

>> To be fair, D's documentation uses a left-side menu, but it removes the top level navigation (you have to press the logo).
> Yep, new design has _same_ solution.

The new design was a rough draft. It also didn't even implement documentation navigation, it merely served as a proof-of-concept.

>> I'd call that more of a design flaw than a feature.
> Do you have more good ideas?

I'd suggest using left navigation for documentation navigation, and a top bar for main site navigation. On small screen width, instead of a left navigation, it'd just be a list for each module page, and a back button on the module pages. I'd have to play with it a bit to figure out how I'd want it for sure though.

On Tuesday, 22 December 2015 at 15:43:29 UTC, Dmitry wrote:
> On Tuesday, 22 December 2015 at 15:17:57 UTC, Adam D. Ruppe wrote:
>> and a good web design should work in all these cases.
> I agree. My message was that current design supports any size, but new design does not support widescreens.

That's ok, but that has nothing to do with percentages of screenview dimensions. It is the browser view and physical width (view angle) that matters.

Designing well for all view sizes is too expensive and cannot be done in the context of this forum. If a webdesigner with a solid background in usability steps up... Ok. If not, keep it simple and consistent.

The most important use case is new D programmers looking at browser and editor. The secondary use case is casual screen view sized browsing e.g. mobile unit.

Both use cases suggest that narrow windows should be a priority.

I am confident that in this context keeping it simple and consistent with a focus on least common denominator for the most important use case: new D programmers solving programming issues -> narrow widths.

As for design there are many solutions, but bikeshedding it a priori will just lead to an inconsistent design with lower usability.

As a former teacher of msc level web design and usability I am pretty sure that for the majority doing a complex and flecible design will lead to worse usability overall.

I am also pretty sure that no usability expert will volunteer in this bike shedding micro management context. If it happens, great. If not, KISS.

On Tuesday, 22 December 2015 at 16:58:40 UTC, Andrei Alexandrescu wrote:
> On 12/22/2015 02:19 AM, Jacob Carlborg wrote:
>> On 2015-12-21 18:37, Andrei Alexandrescu wrote:
>>
>>> That's a large leap. I suggest using Ddoc instead of Sass compact CSS
>>> files, see the existing instance at
>>> https://github.com/D-Programming-Language/dlang.org/blob/master/css/cssmenu.css.dd.
>>>
>>>
>>>
>>> CoffeeScript sounds like a nice thing to add and is from what I've heard
>>> reasonably stable.
>>>
>>> We can't make the site depend on dub at this time. There have been
>>> situations in the past when dub wouldn't build and nobody was available
>>> to work on it. At that time only the alternate documentation got broken,
>>> but if the site depends on it we're looking at catastrophic failure.
>>
>> I have no interest in using Ddoc. If that's a requirement we can close
>> down the redesign idea completely.
>
> I was afraid you were going to say this. Looks like we're reaching an impasse again, so let me explain the situation from where I stand and kindly attempt to change your viewpoint a bit.
>
> One simple matter of fact is that most work and maintenance on dlang.org (https://github.com/D-Programming-Language/dlang.org/graphs/contributors) is done by a handful of folks: Walter, myself, Kenji, Martin, Vladimir, followed by a long tail. Lately it's been Vladimir, Martin, and myself who did most maintenance work.
>
> A consequence of that is when someone proposes a different technology for dlang.org, the proposal is really that Vladimir, Martin, and me become fluent in it. This is a very simple fact that I have had difficulty communicating. I've said several times that the only thing that would make e.g. vibe.d more used on dlang.org is the availability of people able and willing to help with it.
>
> As far as I understand you are well versed in a variety of Web-related tools, and have your preferences in terms of tooling you use etc. That's totally cool. Also, my understanding is that you'd consider helping with the redesign but only as a one-off contribution; there'd be no implied commitment that you'd be available for solving various issues related to the technologies you propose. This makes things more difficult for everyone involved. What would help would be a bit more flexibility with the choices made and more convergence toward compromise. You can't come with a battery of large changes in a take it or leave it manner.
>
>
> Thanks,
>
> Andrei

First question first, how do one create a template from a design so that ddoc can generate using it ?

Also, the home page may be one of these that justify going off road. You often want something more out of the ordinary there as goals are different from the usual doc page. Is that possible to have a custom html (or whatever else) for the home page and keep using ddoc for everything else ?

On 12/23/15 4:59 AM, deadalnix wrote:
> First question first, how do one create a template from a design so that
> ddoc can generate using it ?

I don't understand this question. Ddoc is just pure macro expansion so you can use it in many ways, including to generate a verbatim copy of the input (https://github.com/D-Programming-Language/dlang.org/blob/master/verbatim.ddoc) or a text-only version of the input (https://github.com/D-Programming-Language/dlang.org/blob/master/plaintext.ddoc).

> Also, the home page may be one of these that justify going off road. You
> often want something more out of the ordinary there as goals are
> different from the usual doc page. Is that possible to have a custom
> html (or whatever else) for the home page and keep using ddoc for
> everything else ?

Yah. Overall I think a redesign is needed simply because it's time. Second I think the particular redesign discussed here is nice in many ways. Third I think I'm being reasonable if I ask to introduce new or custom technology dependencies only with good reason.


Andrei

On Wednesday, 23 December 2015 at 17:22:25 UTC, Andrei Alexandrescu wrote:
> Third I think I'm being reasonable if I ask to introduce new or custom technology dependencies only with good reason.
>
>
> Andrei

I think that's very fair.

On your earlier point of getting people to work on the website and also commit to helping out in future, is there an "official" thing here? Like a contract (An unpaid contract, obviously :D)?

Or is it more a matter of trust from you and everyone else involved with the site towards a person stating they'd like to help?