Am 29.07.2014 00:54, schrieb w0rp:
> On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:
>>> I'll look at playing with the style of the documentation pages some more
>>> another evening. I've had a few ideas for improvements, and I obviously
>>> still need to include syntax highlighting. Is this the library which is
>>> being used on the live site now for that?
>>>
>>> https://code.google.com/p/google-code-prettify/
>>
>> That plus some modifications to add D support. But my plan was to use
>> server side highlighting using Brian Schott's lexer in the future.
>
> That's probably a good call. Were you thinking of discovering <code>
> blocks in pages and running the lexer on them to produce the formatted
> output?

The other way around. DDOX and the Markdown processor would directly call the syntax highlighter on code sections they encounter. The result would then directly be written to the output range.

On Tuesday, 29 July 2014 at 08:27:40 UTC, Sönke Ludwig wrote:
> Am 29.07.2014 00:54, schrieb w0rp:
>> On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:
>>>> I'll look at playing with the style of the documentation pages some more
>>>> another evening. I've had a few ideas for improvements, and I obviously
>>>> still need to include syntax highlighting. Is this the library which is
>>>> being used on the live site now for that?
>>>>
>>>> https://code.google.com/p/google-code-prettify/
>>>
>>> That plus some modifications to add D support. But my plan was to use
>>> server side highlighting using Brian Schott's lexer in the future.
>>
>> That's probably a good call. Were you thinking of discovering <code>
>> blocks in pages and running the lexer on them to produce the formatted
>> output?
>
> The other way around. DDOX and the Markdown processor would directly call the syntax highlighter on code sections they encounter. The result would then directly be written to the output range.

Sounds good to me. This is starting to remind me of Inception. A
D website running on vibe.d which invokes a D compiler to produce
D documentation which produces syntax highlighting for D code
blocks using a D lexer.

On Monday, 28 July 2014 at 19:13:12 UTC, Gary Willoughby wrote:
> Do you think users give a hoot how facebook works?

I've seen an expressed concern here (probably by Nick) about facebook using PHP, the latter being a not so good language. In a reddit announcement about dlang forum there was a discussion about whether it's fast because the backend is compiled to native code or because the frontend is optimized.

> We need to 'sell' D, not make it look amateurish.

Yes, but a good LAMP design sells LAMP instead of D.

On Tuesday, 29 July 2014 at 08:51:43 UTC, w0rp wrote:
> On Tuesday, 29 July 2014 at 08:27:40 UTC, Sönke Ludwig wrote:
>> Am 29.07.2014 00:54, schrieb w0rp:
>>> On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:
>>>>> I'll look at playing with the style of the documentation pages some more
>>>>> another evening. I've had a few ideas for improvements, and I obviously
>>>>> still need to include syntax highlighting. Is this the library which is
>>>>> being used on the live site now for that?
>>>>>
>>>>> https://code.google.com/p/google-code-prettify/
>>>>
>>>> That plus some modifications to add D support. But my plan was to use
>>>> server side highlighting using Brian Schott's lexer in the future.
>>>
>>> That's probably a good call. Were you thinking of discovering <code>
>>> blocks in pages and running the lexer on them to produce the formatted
>>> output?
>>
>> The other way around. DDOX and the Markdown processor would directly call the syntax highlighter on code sections they encounter. The result would then directly be written to the output range.
>
> Sounds good to me. This is starting to remind me of Inception. A
> D website running on vibe.d which invokes a D compiler to produce
> D documentation which produces syntax highlighting for D code
> blocks using a D lexer.

Confusing sentence. Deception at it's finest.

/sorry

Random guy here. I think the redesign is good. Populating the On This Page box with the function, enum etc. names would be nice. Preserving some form of site/page link navigation in the narrow mode is essential, be it switching to boxes at the top/bottom of the page or minimizing/maximizing the side bars. But maybe you're already working on that.
Maybe the full width view could have a wider documentation body or dynamically scale up text, but it works fine as it is. As a tree style tabs plus side taskbar user I don't see all that much wasted space. Dynamically adjusting and being readable at half-width is a killer feature over D's current web docs, especially on desktops without workspaces.

First I wanna say that I've become a huge fan of D, and I hope one day I can replace all my creative projects with a D codebase. With that said, I do agree that D could use a redesign. I've not been monitoring this thread very closely, but the design suggestions I've seen so far has dissapointed me. Don't misunderstand me; the proposals look good, but they are in my opinion too conservative.

Now I've given it a shot and created a first draft on how I imagine a future Dlang.org could/should look like, keep in mind that nothing is final yet:

https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the "market". I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy.

(I hope I haven't missed any earlier design proposal that already looks like this.)

On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
> https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png
>
> My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly.

+1 Cool look! The paragraphs need to be black on light background to get high contrast for all user groups, though. (You will also meet resistance on changing the logo...)

> I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy.

The documentation could have black on white (white paper meme), but same visual elements to get a sense of subsite areas.

On 21/08/14 06:59, Hubert wrote:

> https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

I kind of like the structure of the page, but not the colors.

-- 
/Jacob Carlborg

On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
> First I wanna say that I've become a huge fan of D, and I hope one day I can replace all my creative projects with a D codebase. With that said, I do agree that D could use a redesign. I've not been monitoring this thread very closely, but the design suggestions I've seen so far has dissapointed me. Don't misunderstand me; the proposals look good, but they are in my opinion too conservative.
>
> Now I've given it a shot and created a first draft on how I imagine a future Dlang.org could/should look like, keep in mind that nothing is final yet:
>
> https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png
>
> My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the "market". I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy.
>
> (I hope I haven't missed any earlier design proposal that already looks like this.)

It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks.

On Thu, 21 Aug 2014 12:09:37 +0000
Dicebot via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks.
exactly what i wanted to say, but cannot find the appropriate words!