www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Redesign of dlang.org

reply Jacob Carlborg <doob me.com> writes:
Here's another thread about redesign of dlang.org. I'm creating this 
thread because of a couple other threads recently created [1] [2].

The redesign was made by Ivan Smirnov in the beginning of this year. 
I've helped out a bit with suggestions but he has made all the work. I'm 
making it available [3] now because I can't get in contact with him 
anymore and I think that it would be sad to see his work go to waste.

The redesign is just a mock of the start page and a Phobos documentation 
page. No Ddoc, vibe.d or similar is used. Only HTML, JavaScript and Less 
(CSS). It's not a functioning site, it's only to show the design.

A few things are working:

On the start page:

* The "Show example" link on the start page in the "Static type 
inference" section

* The "Documentation -> Standard Library" link in the top menu. This is 
the link to the mock of the Phobos documentation page

On the Phobos documentation page:

* The plus button in the first documented symbol
* The "ForeachType" cross-reference link
* The "isIterable" cross-reference link in the constraint
* The "isNarrowString" cross-reference link in the constraint
* The "isInfinite" cross-reference link in the constraint

On the Phobos doc page, for each symbol it will show the signature. The 
template constraint will be on a separate line in a different color, 
moving the focus to the important parts of the signature. 
Cross-reference links will open a popover with the documentation of the 
referenced symbol.

By default only the summary is shown for a symbol. The rest of the 
documentation is hidden in a collapsible section (the plus button).

Thoughts?

[1] http://forum.dlang.org/thread/ejpuwwlutklvlozyfnqy forum.dlang.org
[2] http://forum.dlang.org/thread/fdbnecqbemseocwzghxw forum.dlang.org
[3] http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM

-- 
/Jacob Carlborg
Dec 19 2015
next sibling parent BLM768 <blm768 gmail.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?


The template constraints being on their own line is a nice touch.

Overall, the design looks very clean-cut. The only real issue I 
see is that it could use a bit more contrast. Those light gray 
lines fade into the background just a bit too much.
Dec 19 2015
prev sibling next sibling parent reply JohnCK <j j.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 ... I'm making it available [3] now...
 [3] http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


Can we see this without sign in?

JohnCK.
Dec 19 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-19 18:12, JohnCK wrote:


 Can we see this without sign in?


Should be accessible.

-- 
/Jacob Carlborg
Dec 19 2015
parent reply Basile B. <b2.temp gmx.com> writes:
On Saturday, 19 December 2015 at 20:55:51 UTC, Jacob Carlborg 
wrote:

 On 2015-12-19 18:12, JohnCK wrote:


 Can we see this without sign in?


 Should be accessible.


No, I do not see it either.
Dec 19 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-19 23:41, Basile B. wrote:


 No, I do not see it either.


I changed the permissions, does it work now?

-- 
/Jacob Carlborg
Dec 19 2015
parent reply JohnCK <j j.com> writes:
On Saturday, 19 December 2015 at 23:11:33 UTC, Jacob Carlborg 
wrote:

 I changed the permissions, does it work now?


Now it's working! Well... it's clean, but of course needs more 
polishing, like taking out a few border colors for example, but 
another thing that I liked was the buttons on top.

JohnCK.
Dec 19 2015
parent reply wobbles <grogan.colin gmail.com> writes:
On Saturday, 19 December 2015 at 23:38:17 UTC, JohnCK wrote:

 On Saturday, 19 December 2015 at 23:11:33 UTC, Jacob Carlborg 
 wrote:

 I changed the permissions, does it work now?


 Now it's working! Well... it's clean, but of course needs more 
 polishing, like taking out a few border colors for example, but 
 another thing that I liked was the buttons on top.

 JohnCK.


Personally I prefer the buttons on the side.
Probably 99% of people have widescreen format now (at leas 16:9), 
so I feel buttons at the top use up precious vertical space.

This is of course all down to preference!

Also, I love how the site handles mobile well. Very nice!
Dec 19 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-20 01:11, wobbles wrote:


 Personally I prefer the buttons on the side.
 Probably 99% of people have widescreen format now (at leas 16:9), so I
 feel buttons at the top use up precious vertical space.


The top menu is 40px high. The left menu of the current dlang.org is 
224px wide. A top menu uses the space more efficient. I also think it's 
easier to adapt for mobile with a top menu.

-- 
/Jacob Carlborg
Dec 20 2015
next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/20/15, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 2015-12-20 01:11, wobbles wrote:


 Personally I prefer the buttons on the side.
 Probably 99% of people have widescreen format now (at leas 16:9), so I
 feel buttons at the top use up precious vertical space.


 The top menu is 40px high. The left menu of the current dlang.org is
 224px wide. A top menu uses the space more efficient. I also think it's
 easier to adapt for mobile with a top menu.


Yeah I agree. Also currently I have to scroll to see the entire menu,
while I wouldn't have to do that with the new layout. If there's more
horizontal space then we should take advantage of it, the new layout
looks great.
Dec 20 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 20 Dec 2015 7:31 pm, "Andrej Mitrovic via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On 12/20/15, Jacob Carlborg via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 2015-12-20 01:11, wobbles wrote:


 Personally I prefer the buttons on the side.
 Probably 99% of people have widescreen format now (at leas 16:9), so I
 feel buttons at the top use up precious vertical space.


 The top menu is 40px high. The left menu of the current dlang.org is
 224px wide. A top menu uses the space more efficient. I also think it's
 easier to adapt for mobile with a top menu.


 Yeah I agree. Also currently I have to scroll to see the entire menu,
 while I wouldn't have to do that with the new layout. If there's more
 horizontal space then we should take advantage of it, the new layout
 looks great.


I'd like to see a more complete menu in the new layout to get a better feel
for it.  It certainly looks the part with the small set of key features of
dlang on display.  But how will it fair showing the entire language or
library reference list items?
Dec 20 2015
next sibling parent JohnCK <j j.com> writes:
On Sunday, 20 December 2015 at 23:20:31 UTC, Iain Buclaw wrote:

 ...But how will it fair showing the entire language or library 
 reference list items?


I think the "Library Reference" link would be there, but the 
"List of Items" NOT. It should have a different page for the list 
or it will be a madness.

JohnCK.
Dec 20 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-21 00:20, Iain Buclaw via Digitalmars-d wrote:


 I'd like to see a more complete menu in the new layout to get a better
 feel for it.  It certainly looks the part with the small set of key
 features of dlang on display.  But how will it fair showing the entire
 language or library reference list items?


There are currently links to the language reference and standard library 
in the menu (Documentation). But there won't be any submenus, as it is 
on the current version of dlang.org. Possibly a left menu would be a 
good fit for this. That is only present on the language reference and 
standard library pages.

-- 
/Jacob Carlborg
Dec 21 2015
prev sibling next sibling parent Jimmy Cao <jc2462 cornell.edu> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 [3] http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


This looks incredible.  I think the layout is a huge improvement 
from the existing one.

I do wish there were a one-click link to the forums on the 
navigation-bar, instead of a Community dropdown.  I personally do 
not like dropdown menus in navigation bars like that.  I'd rather 
only the most important pages be available there as direct links.
Dec 19 2015
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?


Miles ahead of what we have now.
Not only looking good, it's also better on mobile and easier to 
navigate.
Dec 19 2015
prev sibling next sibling parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12/19/15, Jacob Carlborg via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Here's another thread about redesign of dlang.org. I'm creating this
 thread because of a couple other threads recently created [1] [2].

 The redesign was made by Ivan Smirnov in the beginning of this year.
 I've helped out a bit with suggestions but he has made all the work. I'm
 making it available [3] now because I can't get in contact with him
 anymore and I think that it would be sad to see his work go to waste.


Looks incredible!
Dec 19 2015
prev sibling next sibling parent Adrian Matoga <epi atari8.info> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?


Excellent, both for increasing the apparent brand value for 
newcomers and for reducing frustration of existing users. 
Minimalistic, modern, professional and consistent look & feel, 
easy to read and navigate - even at the very first sight at the 
main site one can instantly find what they're looking for.
Dec 19 2015
prev sibling next sibling parent reply Tanel =?UTF-8?B?VGFnYXbDpGxp?= <tanel58 hotmail.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?


I love it.
Especially the navigation bar being horizontal and absolutely 
positioned.
Once I have the time, I could help work on this.
Dec 19 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-12-19 23:09, Tanel Tagaväli wrote:


 I love it.
 Especially the navigation bar being horizontal and absolutely positioned.
 Once I have the time, I could help work on this.


That would be great. Although I don't really want to do anything until 
Walter and Andrei approve the design.

-- 
/Jacob Carlborg
Dec 20 2015
prev sibling next sibling parent reply Jakob Jenkov <jakob jenkov.com> writes:
It looks good. A bit more clear than the current one. Not a fan 
of the drop downs though. Just personal taste.

All in all, though, is that design really so much different from 
the current one? Yes, the frontpage / color scheme looks nicer, 
but it's not that big of a diff, or?

If the D website maintainers are to put an effort into changing 
its design, would it not be preferable to go "all-in" and jazz it 
up, e.g. like http://www.scala-lang.org/ ?

For instance, I am pretty new to D, and when I entered the D 
website I was not looking for code samples, but a list of 
features or core concepts / principles. The code sample on the 
frontpage did nothing for me. But that's just me. I would rather 
know what companies use D, and for what - or what big frameworks 
/ tools were available in D etc.
Dec 19 2015
next sibling parent Jimmy Cao <jc2462 cornell.edu> writes:
On Sunday, 20 December 2015 at 02:04:30 UTC, Jakob Jenkov wrote:

 If the D website maintainers are to put an effort into changing 
 its design, would it not be preferable to go "all-in" and jazz 
 it up, e.g. like http://www.scala-lang.org/ ?


I would like to know this, too.  Scala's website is really 
beautiful.

But, I would prefer a design like https://ocaml.org/ -- simple, 
clean, and efficient.
Dec 19 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-20 03:04, Jakob Jenkov wrote:

 It looks good. A bit more clear than the current one. Not a fan of the
 drop downs though. Just personal taste.

 All in all, though, is that design really so much different from the
 current one? Yes, the frontpage / color scheme looks nicer, but it's not
 that big of a diff, or?

 If the D website maintainers are to put an effort into changing its
 design, would it not be preferable to go "all-in" and jazz it up, e.g.
 like http://www.scala-lang.org/ ?


They have the big background image the adds a lot of color to the site. 
I guess it would be possible to use a background image instead of the 
gray background color at the top.


 For instance, I am pretty new to D, and when I entered the D website I
 was not looking for code samples, but a list of features or core
 concepts / principles.


That would be the "Why D?" section.

-- 
/Jacob Carlborg
Dec 20 2015
prev sibling next sibling parent reply Charles <csmith.ku2013 gmail.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 [...]


kind of a neat project here... mind if I help out?
Dec 19 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-20 06:12, Charles wrote:


 kind of a neat project here... mind if I help out?


Sure, that would be great. Although I don't really want to do anything 
until Walter and Andrei approve the design.

-- 
/Jacob Carlborg
Dec 20 2015
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Sunday, 20 December 2015 at 13:50:53 UTC, Jacob Carlborg wrote:

 On 2015-12-20 06:12, Charles wrote:


 kind of a neat project here... mind if I help out?


 Sure, that would be great. Although I don't really want to do 
 anything until Walter and Andrei approve the design.


Worth noting that this design modifies the logo, which Walter 
vetoed during the previous redesign.
Dec 20 2015
next sibling parent reply Sean Campbell <sycam.inc gmail.com> writes:
On Monday, 21 December 2015 at 05:14:34 UTC, Vladimir Panteleev 
wrote:

 On Sunday, 20 December 2015 at 13:50:53 UTC, Jacob Carlborg 
 wrote:

 On 2015-12-20 06:12, Charles wrote:


 kind of a neat project here... mind if I help out?


 Sure, that would be great. Although I don't really want to do 
 anything until Walter and Andrei approve the design.


 Worth noting that this design modifies the logo, which Walter 
 vetoed during the previous redesign.


It only removes the border, so that it better integrates with the 
top menu.
The difference between the two seem trivial?

This new design for dlang.org is much easier to use. I hope it 
replaces the current one.
Dec 21 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-12-21 09:12, Sean Campbell wrote:


 It only removes the border, so that it better integrates with the top menu.
 The difference between the two seem trivial?


Actually it has changed the red color and I think it removes the gloss 
effect. But the shape of the D and the two moons is the same, which I 
think is the important part.

-- 
/Jacob Carlborg
Dec 21 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-21 06:14, Vladimir Panteleev wrote:


 Worth noting that this design modifies the logo, which Walter vetoed
 during the previous redesign.


Yeah... But as I have tried to explain, it's common for companies to 
have different version of the same logo for different use cases. I think 
this stays true to the original one. The key part of the logo is the D 
and the two moons (or whatever they are), which looks the same on both 
logos.

The Apple's logo for example. It's basically different on each of their 
products. Different sizes, different colors and so on. What is the same 
is the shape and that is what people recognize.

-- 
/Jacob Carlborg
Dec 21 2015
prev sibling parent JohnCK <j j.com> writes:
On Monday, 21 December 2015 at 05:14:34 UTC, Vladimir Panteleev 
wrote:

 Worth noting that this design modifies the logo, which Walter 
 vetoed during the previous redesign.


I don't want to be harsh with Walter, but I think he should 
minding with language design.

You know... look that all companies change their logos from time 
to time, but trying to get a 21s layout with a 90s logo doesn't 
sound good.

JohnCK.
Dec 21 2015
prev sibling parent reply wobbles <grogan.colin gmail.com> writes:
On Sunday, 20 December 2015 at 13:50:53 UTC, Jacob Carlborg wrote:

 On 2015-12-20 06:12, Charles wrote:


 kind of a neat project here... mind if I help out?


 Sure, that would be great. Although I don't really want to do 
 anything until Walter and Andrei approve the design.


On that - have you had any contact / discussion with Walter 
and/or Andrei about this?

I recall there was a thread on this very subject close to a year 
ago but can't remember if there was any decisions made.
Dec 21 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-12-21 14:40, wobbles wrote:


 On that - have you had any contact / discussion with Walter and/or
 Andrei about this?


No, I just put this out there to see what happens.

-- 
/Jacob Carlborg
Dec 21 2015
prev sibling next sibling parent Suliman <evermind live.ru> writes:
Suuuuper!!!
Dec 19 2015
prev sibling next sibling parent rsw0x <anonymous anonymous.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?


looks great
Dec 19 2015
prev sibling next sibling parent Saurabh Das <saurabh.das gmail.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Here's another thread about redesign of dlang.org. I'm creating 
 this thread because of a couple other threads recently created 
 [1] [2].

 [...]


Thanks for doing this, a thorough website redesign is much needed.

The mock up already looks modern and much friendlier than the 
current website.
Dec 20 2015
prev sibling next sibling parent Adam Wilson <flyboynw gmail.com> writes:
PLEASE! For the sake of everything that is good and right in this world, 
let this be a thing!

I don't even care about the drop-downs. This is categorically superior 
to the current site in every relevant way.

Clean, modern, user-friendly, and mobile-friendly design. Easily 
accessible to both Humans and PageRank.

Please make this a thing!

-- 
// Adam Wilson
// quiet.dlang.dev
Dec 20 2015
prev sibling next sibling parent Andrea Fontana <nospam example.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?

 [1] 
 http://forum.dlang.org/thread/ejpuwwlutklvlozyfnqy forum.dlang.org
 [2] 
 http://forum.dlang.org/thread/fdbnecqbemseocwzghxw forum.dlang.org
 [3] http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


IMHO design is nice but on homepage there's too much to read. It 
is disorienting for a newcomer. I think you should reduce 
informations given on the main page. And there's nothing that 
catch the focus: I think you should highlight one part of that 
page using a bigger font size, for example. You need to drive a 
new user that comes there.

Colors are good but on documentation they're too light.

Andrea
Dec 21 2015
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 The redesign is just a mock of the start page and a Phobos 
 documentation page. No Ddoc, vibe.d or similar is used. Only 
 HTML, JavaScript and Less (CSS). It's not a functioning site, 
 it's only to show the design.


Nice! A few suggestions:

1. Red is an attention-seeking colour, so it usually a good idea 
to use it more sparingly. But if you use it on links, make sure 
you only use it on "clickable" items. Right now some icons and 
text are red, but non-clickable.

2. Align the elements. Make the logo horizon unclipped in the 
horizontal direction (complete the sphere) and implement it as 
part of the background, then align the left edge of the D logo 
with the left edge of the content.
Dec 21 2015
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 21 December 2015 at 08:47:48 UTC, Ola Fosheim Grøstad 
wrote:

 idea to use it more sparingly. But if you use it on links, make 
 sure you only use it on "clickable" items.


I personally prefer black text with coloured underline on links. 
Easier on the eyes:

http://www.w3.org/
Dec 21 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-21 09:47, Ola Fosheim Grøstad wrote:


 Nice! A few suggestions:

 1. Red is an attention-seeking colour, so it usually a good idea to use
 it more sparingly. But if you use it on links, make sure you only use it
 on "clickable" items. Right now some icons and text are red, but
 non-clickable.


Most links are dummy links.


 2. Align the elements. Make the logo horizon unclipped in the horizontal
 direction (complete the sphere) and implement it as part of the
 background, then align the left edge of the D logo with the left edge of
 the content.


It's apparently very sensitive to modify the logo.

-- 
/Jacob Carlborg
Dec 21 2015
prev sibling next sibling parent earthfront <earthfront safetymail.info> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?


Fantastic. +1.

The editable and runnable code on the existing homepage is a nice 
touch.
That should find its way into the new homepage.
Dec 21 2015
prev sibling next sibling parent Misu <misugi-pwnu live.fr> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Thoughts?


Wow.

I really like it. Clearly better than the actual design

+1 for me.
Dec 21 2015
prev sibling next sibling parent reply anonymous <anonymous example.com> writes:
On 19.12.2015 15:33, Jacob Carlborg wrote:

 http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


I know you wait for Walter's and Andrei's approval on this before 
investing more work. That's very reasonable. Luckily, I'm not so 
reasonable ;)

http://d-ag0aep6g.rhcloud.com/

On GitHub if people want to play around with it:
https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign

That's a full clone of dlang.org in the new style. I just pasted it over 
the old style, and hacked around on top of it until it worked, more or 
less. It's a quick and dirty showcase. I touched everything, but 
polished nothing. There are more rough edges than smooth ones.

I changed various details from the mock-up (logo, icons, text, ...), so 
this is not a perfect port. In particular, I tried not to throw out 
content and features from the current dlang.org. For now, that is. The 
home page is pretty crowded, and the menu bar definitely needs to be 
streamlined.

By the way, I'm not sold on that font. I think I'd prefer a sans-serif.
Dec 21 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/21/2015 08:58 AM, anonymous wrote:

 On 19.12.2015 15:33, Jacob Carlborg wrote:

 http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


 I know you wait for Walter's and Andrei's approval on this before
 investing more work. That's very reasonable. Luckily, I'm not so
 reasonable ;)

 http://d-ag0aep6g.rhcloud.com/

 On GitHub if people want to play around with it:
 https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign

 That's a full clone of dlang.org in the new style. I just pasted it over
 the old style, and hacked around on top of it until it worked, more or
 less. It's a quick and dirty showcase. I touched everything, but
 polished nothing. There are more rough edges than smooth ones.

 I changed various details from the mock-up (logo, icons, text, ...), so
 this is not a perfect port. In particular, I tried not to throw out
 content and features from the current dlang.org. For now, that is. The
 home page is pretty crowded, and the menu bar definitely needs to be
 streamlined.

 By the way, I'm not sold on that font. I think I'd prefer a sans-serif.


Nice! A few questions.

What are the changes to the tooling used and the build process?

Is there a reasonable decay if javascript is disabled?

Can we defer any changes to the logo so we don't get sidetracked in 
this? Just scale the existing logo to fit and defer any changes to it to 
later.


Thanks,

Andrei
Dec 21 2015
next sibling parent reply anonymous <anonymous example.com> writes:
On 21.12.2015 15:13, Andrei Alexandrescu wrote:

 What are the changes to the tooling used and the build process?


Uh, none? I'm not sure if I understand the question. It's just DDoc, 
CSS, etc, as usual.


 Is there a reasonable decay if javascript is disabled?


I guess, we'd set up dedicated pages as alternatives for the drop-down 
menus. They could be copies of the little overview snippets from the 
home page, or just lists of links.


 Can we defer any changes to the logo so we don't get sidetracked in
 this? Just scale the existing logo to fit and defer any changes to it to
 later.


Fine with me.

Does that mean you are principally on board with this, save for details 
like the logo?
Dec 21 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 December 2015 at 14:54:45 UTC, anonymous wrote:

 I guess, we'd set up dedicated pages as alternatives for the 
 drop-down menus. They could be copies of the little overview 
 snippets from the home page, or just lists of links.


Dedicated pages is a good idea and can be done trivially with 
ddoc macros to avoid repetition of the content in the source.

It could also be a css :hover dropdown instead of JS, but I hate 
drop downs on hover so I'd prefer the dedicated pages.
Dec 21 2015
parent reply BLM768 <blm768 gmail.com> writes:
On Monday, 21 December 2015 at 15:09:06 UTC, Adam D. Ruppe wrote:

 Dedicated pages is a good idea and can be done trivially with 
 ddoc macros to avoid repetition of the content in the source.

 It could also be a css :hover dropdown instead of JS, but I 
 hate drop downs on hover so I'd prefer the dedicated pages.


We could use the :hover dropdowns as a fallback for the JS, 
though. It might not be ideal, but isn't that basically the 
definition of a fallback?
Dec 21 2015
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 December 2015 at 17:52:39 UTC, BLM768 wrote:

 We could use the :hover dropdowns as a fallback for the JS, 
 though. It might not be ideal, but isn't that basically the 
 definition of a fallback?


Yeah, but :hover dropdowns really suck. I'd prefer a fallback 
link over them when given the choice.

The language reference link list is kinda long and could use an 
introductory page anyway. (and I don't mean 
http://dlang.org/spec/intro.html that, I mean a meta-intro that 
describes what the spec is, how it is laid out, etc. so the 
reader knows what to expect from it.)
Dec 21 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-21 15:13, Andrei Alexandrescu wrote:


 Nice! A few questions.

 What are the changes to the tooling used and the build process?


The original code is written in HTML, JavaScript and Less (CSS). See 
repository for build instructions [1]. If I move forward with this I 
would go with vibe.d. I would prefer Sass for the CSS and CoffeeScript 
for the JavaScript.


 Is there a reasonable decay if javascript is disabled?


No. The top menu uses JavaScript and all the collapsible sections 
depends on JavaScript. I hope it's possible to change so the collapsible 
sections are expanded by default.


 Can we defer any changes to the logo so we don't get sidetracked in
 this? Just scale the existing logo to fit and defer any changes to it to
 later.


Using the existing logo in place of the new one looks quite out of 
place. You can easily test that using the developer tools in your 
browser. Right click on the image, choose "Inspect Element", modify the 
"src" attribute of the "img" tag to point to 
"http://dlang.org/images/dlogo.svg".

[1] https://github.com/aldanor/dlang.org-sketch

-- 
/Jacob Carlborg
Dec 21 2015
next sibling parent wobbles <grogan.colin gmail.com> writes:
On Monday, 21 December 2015 at 15:28:44 UTC, Jacob Carlborg wrote:

 The original code is written in HTML, JavaScript and Less 
 (CSS). See repository for build instructions [1]. If I move 
 forward with this I would go with vibe.d.


+1
Dec 21 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/21/2015 10:28 AM, Jacob Carlborg wrote:

 On 2015-12-21 15:13, Andrei Alexandrescu wrote:


 Nice! A few questions.

 What are the changes to the tooling used and the build process?


 The original code is written in HTML, JavaScript and Less (CSS). See
 repository for build instructions [1]. If I move forward with this I
 would go with vibe.d. I would prefer Sass for the CSS and CoffeeScript
 for the JavaScript.


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.


 Is there a reasonable decay if javascript is disabled?


 No. The top menu uses JavaScript and all the collapsible sections
 depends on JavaScript. I hope it's possible to change so the collapsible
 sections are expanded by default.


My understanding is this is a sticky point with some, so probably needs 
fixing before the release.


 Can we defer any changes to the logo so we don't get sidetracked in
 this? Just scale the existing logo to fit and defer any changes to it to
 later.


 Using the existing logo in place of the new one looks quite out of
 place. You can easily test that using the developer tools in your
 browser. Right click on the image, choose "Inspect Element", modify the
 "src" attribute of the "img" tag to point to
 "http://dlang.org/images/dlogo.svg".

 [1] https://github.com/aldanor/dlang.org-sketch


Just defer it and we're good.


Andrei
Dec 21 2015
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 December 2015 at 17:37:11 UTC, 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.


Why is there a $(COLON) macro in there? Is it because of the 
silly section feature of ddoc? Why does it matter at the bottom 
of the file but not in the rest of it?

Using text macros in CSS is something I support. Indeed, my css 
expander does them too, but most of ddoc's other features I fear 
are wrong like the colon thing, and it lacks stuff that is 
specifically useful in css itself like nested selectors. (BTW, 
your _=\n\n pattern is useless, it changes nothing and should be 
removed.)

While I do like using css helper programs... here, I'd prefer to 
just keep the file simple. Let's just write standard CSS, 
understanding that it has a few warts, but then getting the 
benefit of a very easy to understand file for anyone to look at, 
no need to build it, and the possibility of using standard css 
tools on it.


 CoffeeScript sounds like a nice thing to add and is from what 
 I've heard reasonably stable.


Please don't. Coffeescript has distinctly negative value to me, 
including complicating the build process even more, and just 
being a PITA to write.

Again, I'd prefer to keep the javascript files simple too, no 
processors on them. It's not like we need that much of it on this 
site anyway.
Dec 21 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/21/2015 01:04 PM, Adam D. Ruppe wrote:

 On Monday, 21 December 2015 at 17:37:11 UTC, 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.


 Why is there a $(COLON) macro in there? Is it because of the silly
 section feature of ddoc? Why does it matter at the bottom of the file
 but not in the rest of it?


Yeah, that was the reason. I don't remember the specifics.


 Using text macros in CSS is something I support. Indeed, my css expander
 does them too, but most of ddoc's other features I fear are wrong like
 the colon thing, and it lacks stuff that is specifically useful in css
 itself like nested selectors.


Yah, there's always pressure on using the more specialized tool against 
the general one. I wouldn't sell ddoc for css as a product, but for what 
we need here is perfectly appropriate.

The section-with-a-colon thing is something we should probably not do at 
all when compiling .dd files. Keep it for code documentation only.


 (BTW, your _=\n\n pattern is useless, it
 changes nothing and should be removed.)


You must be right, either I was wrong all along or things have changed 
since. Please submit a tested PR?


 While I do like using css helper programs... here, I'd prefer to just
 keep the file simple. Let's just write standard CSS, understanding that
 it has a few warts, but then getting the benefit of a very easy to
 understand file for anyone to look at, no need to build it, and the
 possibility of using standard css tools on it.


Sounds reasonable.


 CoffeeScript sounds like a nice thing to add and is from what I've
 heard reasonably stable.


 Please don't. Coffeescript has distinctly negative value to me,
 including complicating the build process even more, and just being a
 PITA to write.

 Again, I'd prefer to keep the javascript files simple too, no processors
 on them. It's not like we need that much of it on this site anyway.


Nice, too.


Andrei
Dec 21 2015
prev sibling next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 21 December 2015 at 17:37:11 UTC, Andrei Alexandrescu 
wrote:

 On 12/21/2015 10:28 AM, Jacob Carlborg wrote:

 The original code is written in HTML, JavaScript and Less 
 (CSS). See
 repository for build instructions [1]. If I move forward with 
 this I
 would go with vibe.d. I would prefer Sass for the CSS and 
 CoffeeScript
 for the JavaScript.


 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.


IMO we should stay away from trans-plied languages like SCSS, 
Less, and CoffeeScript, for several reasons

1. Everyone who knows the superset already knows the subset

2. Because of 1, going with the superset unnecessarily limits 
your contributor base (I don't know and have no urge to learn 
CoffeeScript for example) for a very small amount of gain

3. The compilers out put ugly, hard to debug code, that also 
tends to be slower

4. We become dependent on their toolchain.

What if CoffeeScript or SCSS ceases to exist, especially since 
Babel is now the fad that has replaced CoffeeScript? E.g. Does 
anyone remember Dart? How many Dart libraries are sitting 
unmaintained now? We have to think 10 years in the future so we 
don't end up rewriting a whole bunch of code and I am willing to 
bet that CoffeeScript will not be maintained in 2020.


 No. The top menu uses JavaScript and all the collapsible 
 sections
 depends on JavaScript. I hope it's possible to change so the 
 collapsible
 sections are expanded by default.


 My understanding is this is a sticky point with some, so 
 probably needs fixing before the release.


Yes, sites should degrade gracefully. Not everyone has JavaScript 
http://kryogenix.org/code/browser/everyonehasjs.html
Dec 21 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/21/2015 02:43 PM, Jack Stouffer wrote:

 IMO we should stay away from trans-plied languages like SCSS, Less, and
 CoffeeScript, for several reasons


[snip]

That sounds reasonable. -- Andrei
Dec 21 2015
parent Charles <csmith.ku2013 gmail.com> writes:
On Monday, 21 December 2015 at 19:54:45 UTC, Andrei Alexandrescu 
wrote:

 On 12/21/2015 02:43 PM, Jack Stouffer wrote:

 IMO we should stay away from trans-plied languages like SCSS, 
 Less, and
 CoffeeScript, for several reasons


 [snip]

 That sounds reasonable. -- Andrei


Meanwhile, we could also consider the [U.S. Government's 
standards] (https://playbook.cio.gov/designstandards/), which do 
explicitly suggest using SCSS. On the other hand, also explicitly 
state not to use Bootstrap.

It also recommends a few different m**w js frameworks (like 
angular), but don't think it mentions coffeescript one way or 
another iirc. From what I've seen, these standards are actually 
exceptionally well written.
Dec 21 2015
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Monday, 21 December 2015 at 19:43:35 UTC, Jack Stouffer wrote:

 IMO we should stay away from trans-plied languages like SCSS, 
 Less, and CoffeeScript, for several reasons


CoffeeScript is a no-no now that Babel (ES6) is around. But you 
probably don't need all that since dlang is a pretty simple site 
where js is only used sparingly. You want to use a minifier 
though.

SCSS, Less and the like solve CSS problems that only become 
apparent in big or modular projects. On small stuff you could 
definitely do without them.
Dec 21 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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.


 Just defer it and we're good.


I think it looks pretty bad and will ruin the design.

-- 
/Jacob Carlborg
Dec 21 2015
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 22 December 2015 at 07:19:48 UTC, Jacob Carlborg 
wrote:

 I have no interest in using Ddoc. If that's a requirement we 
 can close down the redesign idea completely.


Jacob, I really like the design, but how are others supposed to 
contribute, e.g. those who come from the dmd side of things, if 
it's not in ddoc? Not everyone knows HTML. Secondly, all of the 
existing content will have to be converted. And finally, what 
will we do about PDF, epub, and LaTeX generation if everything is 
in HTML?

If you wish to go with another format like Markdown, we get to 
the problems I listed here: 
http://forum.dlang.org/post/pxobzxkhxbobuhrsexje forum.dlang.org


 I think it looks pretty bad and will ruin the design.


But the logo is a rather small part of the overall design. Plus, 
there is the problem of brand recognition. Changing the logo is 
not a small event in the grand scheme of things.
Dec 22 2015
next sibling parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 22 December 2015 at 14:42:35 UTC, Jack Stouffer wrote:

 On Tuesday, 22 December 2015 at 07:19:48 UTC, Jacob Carlborg 
 wrote:

 I have no interest in using Ddoc. If that's a requirement we 
 can close down the redesign idea completely.


 Jacob, I really like the design, but how are others supposed to 
 contribute, e.g. those who come from the dmd side of things, if 
 it's not in ddoc? Not everyone knows HTML.


If you don't know HTML then you probably shouldn't be doing 
webdev. It's basic foundational knowledge. I highly doubt that 
anybody who wants to work on the website has put time into 
learning DDOC but not HTML.
Dec 22 2015
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 22 December 2015 at 14:57:22 UTC, Meta wrote:

 If you don't know HTML then you probably shouldn't be doing 
 webdev.


Most the website is content articles, not web dev.

My ideal situation with the website would probably be a html 
skeleton with ddoc in the contents, providing semantic content 
macros in there.

....which isn't *too* far from where we are now! The html 
skeleton is found in the DDOC macro here:

https://github.com/D-Programming-Language/dlang.org/blob/master/dlang.org.ddoc#L54

(why isn't that in html.ddoc? the multiple files is pretty wtfy 
to me)

Though why ever it uses the ridiculous html pretending to be ddoc 
macros is beyond me.


I have a lot of hatred toward the current state of the website 
and documentation, but ddoc in principle really isn't one of 
them. I don't feel it is enough (we could really use things like 
auto generated tables of contents!) and I'm not married to it 
(though the Phobos inline docs kinda are... let's not forget 
about them), but it isn't that bad.

Just the way we're using it is pretty silly.
Dec 22 2015
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Let me preface this saying I'm mildly on the just-keep-ddoc side 
of things....

On Tuesday, 22 December 2015 at 14:42:35 UTC, Jack Stouffer wrote:

 it's not in ddoc? Not everyone knows HTML.


If you don't know HTML, the ddoc macros the dlang.org site uses 
will be pretty mysterious too. What is $(SPANC)? or $(DIVID), 
without referring to html?


 Secondly, all of the existing content will have to be converted.


Oh, that's trivial! dmd -D literally does that automatically.


 And finally, what will we do about PDF, epub, and LaTeX 
 generation if everything is in HTML?


That's similarly extremely easy, actually IMO quite a bit easier 
than messing with the ddoc macros, because HTML is a very easy 
language to parse and transform, especially if written 
semantically.


 If you wish to go with another format like Markdown, we get to 
 the problems I listed here:


I agree, markdown is gross.



 But the logo is a rather small part of the overall design. 
 Plus, there is the problem of brand recognition. Changing the 
 logo is not a small event in the grand scheme of things.


The new logo design still struck me as the same brand when I 
first saw it.
Dec 22 2015
parent Jacob Carlborg <doob me.com> writes:
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
Dec 22 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 22 2015
parent reply deadalnix <deadalnix gmail.com> writes:
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 ?
Dec 23 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 23 2015
next sibling parent reply wobbles <grogan.colin gmail.com> writes:
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?
Dec 23 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/23/2015 04:35 PM, wobbles wrote:

 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?


There is no contract, only a matter of building a history of good 
contributions. -- Andrei
Dec 23 2015
prev sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Wednesday, 23 December 2015 at 17:22:25 UTC, Andrei 
Alexandrescu wrote:

 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.


That is very reasonable I too think but isn't it a question of 
viewpoint?
I see the dependency chain for a Website as follows:

1) HTML
2) HTML, CSS
3) HTML, CSS, Javascript

It seems that the dlang.org Homepage needs CSS and Javascript so 
3 is the minimal dependency chain.
Ddoc is an additional dependency already and might be more 
efficient to insiders but to outsiders it is an obstacle.
I think you are right in saying that the site should be build 
with technologies you are most efficient with but you should also 
consider the obstacle you are building up by this.
It's hard to estimate the outcome of dropping ddoc but you might 
get more helpers by this move.

So I guess it's a question of how many contributers you get by 
removing ddoc which nobody is able to tell beforehand.
For this reason why not just try to go without it for now and 
decide later on if it is worth it or not.
I can't imagine that you loose that much efficiency by dropping 
ddoc for some time and I don't think it would be that much work 
to switch to ddoc later on.
But on the other hand I don't have a clue and might be totally 
wrong. :-)

By this decision you would also get a contributor who is willing 
to build the initial site which is propably the hardest thing to 
do.
Dec 23 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/24/2015 01:14 AM, Thomas Mader wrote:

 That is very reasonable I too think but isn't it a question of viewpoint?
 I see the dependency chain for a Website as follows:

 1) HTML
 2) HTML, CSS
 3) HTML, CSS, Javascript

 It seems that the dlang.org Homepage needs CSS and Javascript so 3 is
 the minimal dependency chain.
 Ddoc is an additional dependency already and might be more efficient to
 insiders but to outsiders it is an obstacle.
 I think you are right in saying that the site should be build with
 technologies you are most efficient with but you should also consider
 the obstacle you are building up by this.
 It's hard to estimate the outcome of dropping ddoc but you might get
 more helpers by this move.

 So I guess it's a question of how many contributers you get by removing
 ddoc which nobody is able to tell beforehand.
 For this reason why not just try to go without it for now and decide
 later on if it is worth it or not.
 I can't imagine that you loose that much efficiency by dropping ddoc for
 some time and I don't think it would be that much work to switch to ddoc
 later on.
 But on the other hand I don't have a clue and might be totally wrong. :-)

 By this decision you would also get a contributor who is willing to
 build the initial site which is propably the hardest thing to do.


Currently dlang.org has over 62KLOC of Ddoc source, so any significant 
surgery on it will be a large effort. Dropping ddoc means we'd need to 
use another templating engine (getting back to raw html would be too 
much trouble), and 10 people have 11 ideas about which template engine 
is used by "everyone".

I can give you right now an estimate - dropping ddoc and replacing it 
with vibe.d is unlikely to be a landslide success. When the alternate 
documentation was introduced using vibe.d, my hope was that everybody 
would be all over it like a cheap white suit on rice, and that the use 
of vibe.d would organically grow to make the stdlib documentation 
stellar, and then engulf the main site. Sadly participation was scant, 
and we had a couple of vibe.d-related situations in which the maintainer 
division (ahem... Vladimir and myself) had no idea on what to do and had 
nobody to rely on.

Let me put that another way: for folks who want to improve dlang.org but 
for whom ddoc is an impediment, the option exists TODAY to work on large 
parts of the site that have nothing to do with it. Yet from what I can 
tell nobody is taking it. Would you have an interest? (Serious question.)


Thanks,

Andrei
Dec 23 2015
next sibling parent reply Thomas Mader <thomas.mader gmail.com> writes:
On Thursday, 24 December 2015 at 06:43:32 UTC, Andrei 
Alexandrescu wrote:

 Currently dlang.org has over 62KLOC of Ddoc source, so any 
 significant surgery on it will be a large effort. Dropping ddoc 
 means we'd need to use another templating engine (getting back 
 to raw html would be too much trouble), and 10 people have 11 
 ideas about which template engine is used by "everyone".

 I can give you right now an estimate - dropping ddoc and 
 replacing it with vibe.d is unlikely to be a landslide success. 
 When the alternate documentation was introduced using vibe.d, 
 my hope was that everybody would be all over it like a cheap 
 white suit on rice, and that the use of vibe.d would 
 organically grow to make the stdlib documentation stellar, and 
 then engulf the main site. Sadly participation was scant, and 
 we had a couple of vibe.d-related situations in which the 
 maintainer division (ahem... Vladimir and myself) had no idea 
 on what to do and had nobody to rely on.


Thanks for those details your decision is much more clear now for 
me.
I didn't know that the documentation is switched to vibe.d 
already. So I guess everything comes down to the following 
question. Do you want to drop vibe.d or ddoc as a templating 
engine for the site?
Using both doesn't seem to make any sense and for me it's not 
clear which way you want to go.
I remember the decision being made that vibe.d should be more 
tightly integrated into D and if that is still true the question 
for the templating engine seems to already be settled.
If thats correct then allowing Jacob to do the work with vibe.d 
seems to bring you one step further to the goal to introduce 
vibe.d


 Let me put that another way: for folks who want to improve 
 dlang.org but for whom ddoc is an impediment, the option exists 
 TODAY to work on large parts of the site that have nothing to 
 do with it. Yet from what I can tell nobody is taking it. Would 
 you have an interest? (Serious question.)


At the moment my interest in Web Development is pretty low but I 
am interested to fix errors and add content as I see fit.
For that it's nice if the hurdle is as low as possible.
For me it probably doesn't make any difference if I need to use 
vibe.d or ddoc since I don't know them but I guess one of them is 
better suited for the task.
Dec 24 2015
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/24/15 8:26 AM, Thomas Mader wrote:

 On Thursday, 24 December 2015 at 06:43:32 UTC, Andrei Alexandrescu wrote:

 Currently dlang.org has over 62KLOC of Ddoc source, so any significant
 surgery on it will be a large effort. Dropping ddoc means we'd need to
 use another templating engine (getting back to raw html would be too
 much trouble), and 10 people have 11 ideas about which template engine
 is used by "everyone".

 I can give you right now an estimate - dropping ddoc and replacing it
 with vibe.d is unlikely to be a landslide success. When the alternate
 documentation was introduced using vibe.d, my hope was that everybody
 would be all over it like a cheap white suit on rice, and that the use
 of vibe.d would organically grow to make the stdlib documentation
 stellar, and then engulf the main site. Sadly participation was scant,
 and we had a couple of vibe.d-related situations in which the
 maintainer division (ahem... Vladimir and myself) had no idea on what
 to do and had nobody to rely on.


 Thanks for those details your decision is much more clear now for me.
 I didn't know that the documentation is switched to vibe.d already. So I
 guess everything comes down to the following question. Do you want to
 drop vibe.d or ddoc as a templating engine for the site?
 Using both doesn't seem to make any sense and for me it's not clear
 which way you want to go.


At the top level we all want a nice site, not to use or avoid specific 
technologies. We also need a site that the maintenance team can maintain 
effectively. This is something that tends to be forgotten.

We now added some use of vibe.d because (a) there was a champion who did 
the work (thanks Sönke! Also I recall Martin worked on that a bit), (b) 
it has advantages over ddoc, (c) there was hope that others will pick up 
on it.

Things have not yet reached critical mass. Giving up on vibe.d right now 
sounds like quite a bad decision. We'd lose some nice documentation, but 
more importantly we'd compromise the idea of reform of dlang.org. 
Conversely, replacing ddoc with vibe.d is not only a one-time effort, 
but effectively a maintenance burden for which we don't have enough 
qualified people.


 I remember the decision being made that vibe.d should be more tightly
 integrated into D and if that is still true the question for the
 templating engine seems to already be settled.
 If thats correct then allowing Jacob to do the work with vibe.d seems to
 bring you one step further to the goal to introduce vibe.d


Again: vibe.d is being already used at dlang.org, yet it has seen little 
pickup. The key to making vibe.d successful on dlang.org is more folks 
fluent in vibe.d willing to help on a regular basis, not more drive-by work.


Andrei
Dec 24 2015
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 24 December 2015 at 06:43:32 UTC, Andrei 
Alexandrescu wrote:

 Currently dlang.org has over 62KLOC of Ddoc source, so any 
 significant surgery on it will be a large effort. Dropping ddoc 
 means we'd need to use another templating engine (getting back 
 to raw html would be too much trouble), and 10 people have 11 
 ideas about which template engine is used by "everyone".


Because using text editor that can auto complete html is too much 
to ask?
 From what I saw most Ddoc is used to make simple html tags like 
$(P text) is translated to <p>text</p> so running few regex 
replace should fix that. Unless there are some macros that are 
more advanced.


 When the alternate documentation was introduced using vibe.d, 
 my hope was that everybody would be all over it like a cheap 
 white suit on rice


What skills web developers have: html/css, javascript, PHP, 
MySQL, Apache.

What skills are needed for dlang.org: CSS, javascript, make 
files, ddoc, D, dub, Vibe.d and its own way of generating html.

Not to mention that dlang has unique way of generating static 
html pages

You are not making it more accessible by adding one more 
technology that is not usually used for web development.

Here is how various languages are embedded in html
PHP: <?php code ?> or <? code ?>
Ruby on rails: <% code %>
Django(python): {% code %}
Hack: <?hh {code}
D: can`t.

Why cant D be used like all other web languages? (rhetorical 
question)

It would be nice if there were possibility of writing html with 
<?d code ?> in html and with structure like this:

<?d= include("header.dd");?>
<div>
<?d= content ?>
</div>
<?d=include("footer.dd");?>

and rdmd.dd could be found in folder views/Compilers&Tools/

this way any PHP, Ruby, Python, Hack developer could just look at 
dlang.org project and feel at home.

Todays system might not be terrible, but lack of documentation 
was a deal breaker for me. I wanted to fiddle with website layout 
and here how it went.

Welkam followed instructions and successfully generated html 
files. Why welkam needed to compile new dmd is not clear. Then 
welkam opened dlang.org folder. He saw 155 items and sighed. 
Anyway he wanted to edit documentation so the mess didnt bothered 
too much so he opened 
/home/welkam/D/dlang.org/dpl-docs/source/app.d. "I need to look 
at posix.mak to better understand how this page is built" - he 
said, but after looking at mak file he got more confused, because 
he doesnt understand make language. Welkam gave up and decided 
that editing html of one page would be easier for him and if he 
created something useful he would ask some help implementing it.
Jan 06 2016
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-06 15:35, welkam wrote:


 You are not making it more accessible by adding one more technology that
 is not usually used for web development.

 Here is how various languages are embedded in html
 PHP: <?php code ?> or <? code ?>
 Ruby on rails: <% code %>
 Django(python): {% code %}
 Hack: <?hh {code}
 D: can`t.

 Why cant D be used like all other web languages? (rhetorical question)

 It would be nice if there were possibility of writing html with <?d code
 ?> in html and with structure like this:

 <?d= include("header.dd");?>
 <div>
 <?d= content ?>
 </div>
 <?d=include("footer.dd");?>


https://vibed.org/templates/diet

-- 
/Jacob Carlborg
Jan 06 2016
parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 6 January 2016 at 17:14:03 UTC, Jacob Carlborg 
wrote:

 https://vibed.org/templates/diet


I am aware of it, but that is one more technology to learn and 
how is it better?
How left one is more readable than right?
http://i.imgur.com/7KiehRI.png
Jan 06 2016
next sibling parent mate <aiueo aiueo.aiueo> writes:
On Thursday, 7 January 2016 at 02:46:30 UTC, welkam wrote:

 On Wednesday, 6 January 2016 at 17:14:03 UTC, Jacob Carlborg 
 wrote:

 https://vibed.org/templates/diet


 I am aware of it, but that is one more technology to learn and 
 how is it better?
 How left one is more readable than right?
 http://i.imgur.com/7KiehRI.png


Well, this is biased because you only have one side with syntax 
highlighting.
Jan 06 2016
prev sibling parent reply Yazan D <invalid email.com> writes:
On Thu, 07 Jan 2016 02:46:30 +0000, welkam wrote:


 How left one is more readable than right? http://i.imgur.com/7KiehRI.png


Tip: you can use Jade syntax highlighting for diet templates.
Jan 07 2016
parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 7 January 2016 at 08:16:45 UTC, Yazan D wrote:

 On Thu, 07 Jan 2016 02:46:30 +0000, welkam wrote:


 How left one is more readable than right? 
 http://i.imgur.com/7KiehRI.png


 Tip: you can use Jade syntax highlighting for diet templates.


http://i.imgur.com/oaUkjGe.png am I doing something wrong?

For straight html I dont need to do anything and with auto 
complete there is no pain in writing html.

People arguing with me probably dont understand why iPhone became 
so popular also.
Jan 07 2016
parent Yazan D <invalid email.com> writes:
I am not sure.. But you can install this for jade syntax highlighting 
(https://packagecontrol.io/packages/Jade)
Jan 07 2016
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 6 January 2016 at 14:35:13 UTC, welkam wrote:

 Here is how various languages are embedded in html
 PHP: <?php code ?> or <? code ?>
 Ruby on rails: <% code %>
 Django(python): {% code %}
 Hack: <?hh {code}
 D: can`t.


Good, everybody want to get away from this. This was a mistake.
Jan 06 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 6 January 2016 at 17:18:08 UTC, deadalnix wrote:

 Good, everybody want to get away from this. This was a mistake.


quoted for truth
Jan 06 2016
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 December 2015 at 13:58:30 UTC, anonymous wrote:

 I know you wait for Walter's and Andrei's approval on this 
 before investing more work. That's very reasonable. Luckily, 
 I'm not so reasonable ;)

 http://d-ag0aep6g.rhcloud.com/


Huh, that's mildly buggy but I'm actually pretty impressed with 
it.

If it was my decision, I think I'd greenlight this then do a few 
little tweaks myself on staging.
Dec 21 2015
next sibling parent reply JohnCK <j j.com> writes:
On Monday, 21 December 2015 at 14:46:23 UTC, Adam D. Ruppe wrote:

 On Monday, 21 December 2015 at 13:58:30 UTC, anonymous wrote:

 I know you wait for Walter's and Andrei's approval on this 
 before investing more work. That's very reasonable. Luckily, 
 I'm not so reasonable ;)

 http://d-ag0aep6g.rhcloud.com/


 Huh, that's mildly buggy but I'm actually pretty impressed with 
 it.


Unfortunately it's buggy, like for example in 1024x768px it 
doesn't looks good:

http://i.imgur.com/obCcWyd.png

JohnCK.
Dec 21 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 December 2015 at 15:01:16 UTC, JohnCK wrote:

 Unfortunately it's buggy, like for example in 1024x768px it 
 doesn't looks good:


Yeah, the header wraps on my computer on 1280 too, but these are 
mild bugs that can be fixed with a little css adjustment.
Dec 21 2015
parent JohnCK <j j.com> writes:
On Monday, 21 December 2015 at 15:07:05 UTC, Adam D. Ruppe wrote:

 On Monday, 21 December 2015 at 15:01:16 UTC, JohnCK wrote:

 Unfortunately it's buggy, like for example in 1024x768px it 
 doesn't looks good:


 Yeah, the header wraps on my computer on 1280 too, but these 
 are mild bugs that can be fixed with a little css adjustment.


Yes but there are other problems like the code example on the 
right, with was wrapped and the space left in middle (Bellow the 
Download and ChangeLog).

JohnCK.
Dec 21 2015
prev sibling parent reply anonymous <anonymous example.com> writes:
On 21.12.2015 15:46, Adam D. Ruppe wrote:

 Huh, that's mildly buggy but I'm actually pretty impressed with it.


It's definitely very buggy. This is nowhere near releasable quality. I 
put this up so that we have a better preview of the thing. I always feel 
like mock-ups glance over the pain points.
Dec 21 2015
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 December 2015 at 15:07:18 UTC, anonymous wrote:

 It's definitely very buggy. This is nowhere near releasable 
 quality.


Let's not underestimate, but let's not overestimate either, I'm 
pretty confident these bugs could all be fixed in a day of 
tweaking, probably less than that. It looks reasonable right now.
Dec 21 2015
parent reply anonymous <anonymous example.com> writes:
On 21.12.2015 16:45, Adam D. Ruppe wrote:

 Let's not underestimate, but let's not overestimate either, I'm pretty
 confident these bugs could all be fixed in a day of tweaking, probably
 less than that. It looks reasonable right now.


Possibly, but the whole thing still needs to be implemented properly. I 
just added all the CSS from the mock-up on top of the existing stuff. We 
don't want to keep it that way.

Finding all the little issues in the different sections of the site may 
take its time, too. And then there are forum.dlang.org and 
visuald.dlang.org.

Also, things like the overcrowded menu bar, and overly long code 
snippets (on the home page) need decisions, which can take a while if 
people are not in immediate agreement.

On doing it right, I'm not sure how to approach the Bootstrap grid 
thing. Use it with raw HTML/CSS? That may be more complicated than just 
doing things without a framework like that. And switching dlang.org over 
to some preprocessor is not trivial, and may be deemed "too disruptive 
for too little gain".
Dec 21 2015
next sibling parent Bubbasaur <bubba gmail.com> writes:
On Monday, 21 December 2015 at 16:50:31 UTC, anonymous wrote:

 On 21.12.2015 16:45, Adam D. Ruppe wrote:

 Let's not underestimate, but let's not overestimate either, 
 I'm pretty
 confident these bugs could all be fixed in a day of tweaking, 
 probably
 less than that. It looks reasonable right now.


 Possibly, but the whole thing still needs to be implemented 
 properly. I just added all the CSS from the mock-up on top of 
 the existing stuff. We don't want to keep it that way.

 Finding all the little issues in the different sections of the 
 site may take its time, too. And then there are forum.dlang.org 
 and visuald.dlang.org...


Don't forget... less is good: http://motherfuckingwebsite.com/

Bubba.
Dec 21 2015
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 21 December 2015 at 16:50:31 UTC, anonymous wrote:

 Possibly, but the whole thing still needs to be implemented 
 properly. I just added all the CSS from the mock-up on top of 
 the existing stuff. We don't want to keep it that way.


Guess who wrote a program to clean that up semi-automatically 
just two weeks ago? In D, too!


 On doing it right, I'm not sure how to approach the Bootstrap 
 grid thing.


Death to bootstrap.
Dec 21 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-12-21 14:58, anonymous wrote:

 On 19.12.2015 15:33, Jacob Carlborg wrote:

 http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


 I know you wait for Walter's and Andrei's approval on this before
 investing more work. That's very reasonable. Luckily, I'm not so
 reasonable ;)

 http://d-ag0aep6g.rhcloud.com/

 On GitHub if people want to play around with it:
 https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign


This is the original repository from Ivan [1].

[1] https://github.com/aldanor/dlang.org-sketch

-- 
/Jacob Carlborg
Dec 21 2015
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Monday, 21 December 2015 at 13:58:30 UTC, anonymous wrote:

 On 19.12.2015 15:33, Jacob Carlborg wrote:

 http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


 I know you wait for Walter's and Andrei's approval on this 
 before investing more work. That's very reasonable. Luckily, 
 I'm not so reasonable ;)

 http://d-ag0aep6g.rhcloud.com/



Please work towards greenlighting this!
This might be a big, big thing for D adoption and perception.
A prominent download button and call to actions can increase 
conversions manyfold.
Dec 21 2015
prev sibling parent reply anonymous <anonymous example.com> writes:
On 21.12.2015 14:58, anonymous wrote:

 http://d-ag0aep6g.rhcloud.com/

 On GitHub if people want to play around with it:
 https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign

 That's a full clone of dlang.org in the new style. I just pasted it over
 the old style, and hacked around on top of it until it worked, more or
 less. It's a quick and dirty showcase. I touched everything, but
 polished nothing. There are more rough edges than smooth ones.


Since Andrei and Jacob are having creative differences, I figured I'd 
just go ahead with this my way, without changes to the tooling.

This is a more proper implementation of the redesign than what I showed 
before:


http://d-ag0aep6g.rhcloud.com/

https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign


It's far from done, and I don't know if I'm going to work more on it 
over the holidays. So next year maybe.

Todo/notes:

* Legalities

What's the legal status of this? Did Ivan Smirnov give his permission to 
use the visuals? If not, can we get it, do we need it?

* Reorganization of the menu

I reorganized the menu quite a bit. The layout simply doesn't allow for 
many top level items. I don't think it's for the worse.

* Logo

Using the current D logo for now.

* Medium width menu bar

Try making the browser narrower until the main menu bar has two lines of 
text. I don't like that solution, but switching to the layout with the 
menu button seems silly at that point. Suggestions welcome.

* Subnav on narrow screens

Example: http://d-ag0aep6g.rhcloud.com/spec/intro.html

Can't have it as a side bar when the window is too narrow. Solution 
could be to have a link back to a dedicated TOC page instead. 
Suggestions welcome.

* "your code here" height

Many "your code here" snippets are too long. Cut them down, or change 
the layout to accommodate for them? I'd go with cutting them down. That 
may make the whole "your code here" idea pointless.

* Fonts

Do we go with Roboto Slab? What fallback fonts to use, and in what 
order? Candidates from the current dlang.org and from the mock-up are: 
Helvetica, Verdana, Arial, Deja Vu, BitStream Vera Sans.

I didn't adopt the monospace font from the mock-up, because it looked 
pretty bad to me (rather wide, isn't it?). Plain 'monospace' is DejaVu 
Sans Mono on my system. That one looks better, imo.

* That blank space below "Documentation" on the home page

If anyone has an idea on how to stuff it, shoot.

* Forum and twitter widgets

Does anyone make use of these? I'd totally throw them out, but it may 
better to be conservative for now. Have to style them properly then.

* forum.dlang.org and visuald.dlang.org

... will have to be updated, too. I think this is a good opportunity to 
unify the menu situation.

* "Home" link?

Do we need a named Home link in the menu bar, or is the clickable logo 
enough? There is no other way to get to the home page.

* "your code here" link

Would be nice if the subject line could be prefilled with "[your code 
here]".

* Javascript fallbacks

Simply haven't done those, yet.

* Deletions that would maybe go under the radar

These things were beloved by some (i.e. Andrei), but in the redesign 
they are no more:

   * the Slogan
       The D Programming Language
       Modern convenience. Modeling power. Native efficiency.
   * justified text (can easily make a comeback)
   * the GitHub ribbon in the upper right corner on the download page
Dec 24 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/24/15 2:33 PM, anonymous wrote:

 This is a more proper implementation of the redesign than what I showed
 before:


 http://d-ag0aep6g.rhcloud.com/

 https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign


I like it a lot! -- Andrei
Dec 24 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 24/12/15 20:33, anonymous wrote:

 On 21.12.2015 14:58, anonymous wrote:

 http://d-ag0aep6g.rhcloud.com/

 On GitHub if people want to play around with it:
 https://github.com/aG0aep6G/dlang.org/tree/Ivan-Smirnov's-redesign

 That's a full clone of dlang.org in the new style. I just pasted it over
 the old style, and hacked around on top of it until it worked, more or
 less. It's a quick and dirty showcase. I touched everything, but
 polished nothing. There are more rough edges than smooth ones.


 Since Andrei and Jacob are having creative differences, I figured I'd
 just go ahead with this my way, without changes to the tooling.

 This is a more proper implementation of the redesign than what I showed
 before:


 http://d-ag0aep6g.rhcloud.com/


Most of the pages do not seem to be updated.

The drop down in the search fields looks very bad in Safari on OS X. I 
think this is a general problem with bootstrap. I remember having the 
same problem when I used bootstrap. In general I recommend using either 
Boostrap Select [1] or a Bootstrap drop down button [2]. For this 
particular case I recommend using either a field with a button with a 
drop down [3] or placing a magnifier icon to the left inside the search 
field and make a drop down menu out of that icon. The latter option is 
usually how native search fields look like and work on OS X.

[1] https://silviomoreto.github.io/bootstrap-select/examples/
[2] http://getbootstrap.com/components/#btn-dropdowns
[3] http://getbootstrap.com/components/#input-groups-buttons-dropdowns

-- 
/Jacob Carlborg
Dec 25 2015
parent reply anonymous <anonymous example.com> writes:
On 25.12.2015 12:51, Jacob Carlborg wrote:

 Most of the pages do not seem to be updated.


I don't know what you mean. Could this be a cache thing? Can you give a 
specific example, maybe with a screenshot?


 The drop down in the search fields looks very bad in Safari on OS X. I
 think this is a general problem with bootstrap.


This version doesn't use Bootstrap anymore. I just changed some details 
from the current dlang.org, the core mechanism should work the same.

If the current dlang.org looks ok, but mine doesn't, then I must have 
messed up something. It looks fine for me, though, and I have no OS X 
around to check. Further assistance would be appreciated.
Dec 25 2015
next sibling parent Charles <csmith.ku2013 gmail.com> writes:
On Friday, 25 December 2015 at 14:04:36 UTC, anonymous wrote:

 On 25.12.2015 12:51, Jacob Carlborg wrote:

 Most of the pages do not seem to be updated.


 I don't know what you mean. Could this be a cache thing? Can 
 you give a specific example, maybe with a screenshot?


 The drop down in the search fields looks very bad in Safari on 
 OS X. I
 think this is a general problem with bootstrap.


 This version doesn't use Bootstrap anymore. I just changed some 
 details from the current dlang.org, the core mechanism should 
 work the same.

 If the current dlang.org looks ok, but mine doesn't, then I 
 must have messed up something. It looks fine for me, though, 
 and I have no OS X around to check. Further assistance would be 
 appreciated.


I'm away from my computer atm, so I'll just point you to 
www.browserstack.com. It's also free for open source projects. 
Test to your heart's content.
Dec 25 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 25/12/15 15:04, anonymous wrote:


 I don't know what you mean. Could this be a cache thing? Can you give a
 specific example, maybe with a screenshot?


No, it's not a cache thing, the new top menu is there. What I mean is 
that the Phobos documentation (for example) doesn't use the new design. 
Same syntax colors for the syntax highlighting, same green color for the 
Phobos docs and so on.


 This version doesn't use Bootstrap anymore. I just changed some details
 from the current dlang.org, the core mechanism should work the same.

 If the current dlang.org looks ok, but mine doesn't, then I must have
 messed up something. It looks fine for me, though, and I have no OS X
 around to check. Further assistance would be appreciated.


It looks exactly like the problem I had with Bootstrap on OS X. It was 
only a problem on OS X, perhaps on some specific version of Windows as 
well. This is how it looks like for me using Safari on OS X [1]. This is 
the bug I reported to Bootstrap [2].

[1] https://drive.google.com/open?id=0B7UtafxGD9vEQmFxT0d1T1JiU1E
[2] https://github.com/twbs/bootstrap/issues/7602

-- 
/Jacob Carlborg
Dec 26 2015
parent reply anonymous <anonymous example.com> writes:
On 26.12.2015 13:19, Jacob Carlborg wrote:


 No, it's not a cache thing, the new top menu is there. What I mean is
 that the Phobos documentation (for example) doesn't use the new design.
 Same syntax colors for the syntax highlighting, same green color for the
 Phobos docs and so on.


Yeah, I hadn't looked into those, yet. Did so now just now, and updated 
the site. I'm not so sure about coloring the documented symbols the same 
way as links, though. Maybe some nice blue/green/cyan instead of the 
link red?

For now, I'm not going to try to implement the expandable phobos docs or 
the cross references, because they're non-trivial and I think they can 
be done later on. Also, Adam apparently has similar plans for the phobos 
docs. I think I'll wait and see what comes from that, first.


 This is how it looks like for me using Safari on OS X [1]. This is
 the bug I reported to Bootstrap [2].

 [1] https://drive.google.com/open?id=0B7UtafxGD9vEQmFxT0d1T1JiU1E
 [2] https://github.com/twbs/bootstrap/issues/7602


Does that mean I just have to add `-webkit-appearance: none;` to the 
select element? Did that just now. Does it work?
Dec 26 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-26 18:27, anonymous wrote:


 Does that mean I just have to add `-webkit-appearance: none;` to the
 select element? Did that just now. Does it work?


It does work, but it looks like it affected other bowers as well 
(Firefox). BTW, I still think that a custom look would be better. 
Something like the search field in Firefox. It has a the magnifier icon 
which acts like a menu.

-- 
/Jacob Carlborg
Dec 26 2015
parent reply anonymous <anonymous example.com> writes:
On 26.12.2015 21:21, Jacob Carlborg wrote:

 It does work, but it looks like it affected other bowers as well
 (Firefox).


That's weird. Does it look bad?


 BTW, I still think that a custom look would be better.
 Something like the search field in Firefox. It has a the magnifier icon
 which acts like a menu.


I'm hesitating to go that way, because:
a) I don't want to put more on my plate than necessary at this point.
b) It would require Javascript, right? That's not a problem in itself, 
but figuring out a good fallback mechanism seems to be difficult here.
Dec 27 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-27 13:06, anonymous wrote:

 That's weird. Does it look bad?


https://drive.google.com/open?id=0B7UtafxGD9vEQTVjeXZhSDdRZDA


 b) It would require Javascript, right?


I have no idea.

-- 
/Jacob Carlborg
Dec 27 2015
parent reply anonymous <anonymous example.com> writes:
On 27.12.2015 15:04, Jacob Carlborg wrote:

 https://drive.google.com/open?id=0B7UtafxGD9vEQTVjeXZhSDdRZDA


The caret seems to be a bit high maybe, but otherwise that's how it's 
supposed to look. Feel free to criticize, of course.
Dec 27 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-12-27 21:42, anonymous wrote:


 The caret seems to be a bit high maybe, but otherwise that's how it's
 supposed to look. Feel free to criticize, of course.


Aha, then there's no problem :)

-- 
/Jacob Carlborg
Dec 29 2015
prev sibling next sibling parent reply Dmitry <dmitry indiedev.ru> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 Here's another thread about redesign of dlang.org. I'm creating


I want say that there are also people who most like the current 
design.
Dec 21 2015
parent reply Bubbasaur <bubba gmail.com> writes:
On Monday, 21 December 2015 at 20:44:06 UTC, Dmitry wrote:

 On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
 wrote:

 Here's another thread about redesign of dlang.org. I'm creating


 I want say that there are also people who most like the current 
 design.


Why? Reasons?
Dec 21 2015
parent reply Dmitry <dmitry indiedev.ru> writes:
On Monday, 21 December 2015 at 21:20:44 UTC, Bubbasaur wrote:

 I want say that there are also people who most like the 
 current design.


 Why? Reasons?


Basic things:

Left-side menu. I don't like when site uses only half of screen 
(is anybody still uses 1280*1024 and 1024*768 displays? Statistic 
of November says that 5% and 2% of people). New design prepared 
for 4:3, not for wide-screen displays (1920*1080 - 35%, 1366*768 
- 26%, etc).

Good font (Verdana) - I can read it easy, it's comfortable for 
eyes. New design uses Roboto Slab - it's more compact and reading 
speed is more slow (yep, my English is bad and it difficult x2 
times for me).

I like colors (dark theme) which uses current design.

I like that I can unfold multiple/all menu items, not only one.

Of course, current design are not perfect, but it's more cosy.
Dec 21 2015
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 22 December 2015 at 06:38:24 UTC, Dmitry wrote:

 Left-side menu. I don't like when site uses only half of screen 
 (is anybody still uses 1280*1024 and 1024*768 displays? 
 Statistic of November says that 5% and 2% of people). New 
 design prepared for 4:3, not for wide-screen displays 
 (1920*1080 - 35%, 1366*768 - 26%, etc).


I use exclusively 4:3 and 3:4, 1600*1280, 1280*1024, 1024*1280, 
1024*768 and 768*1024.
Widescreen is for movies...

Besides, many programmers with wide screen does not have multiple 
monitors, so they need space both for website and editor on same 
screen.
Dec 22 2015
parent reply Dmitry <dmitry indiedev.ru> writes:
On Tuesday, 22 December 2015 at 08:04:29 UTC, Ola Fosheim Grøstad 
wrote:

 I use exclusively 4:3 and 3:4, 1600*1280, 1280*1024, 1024*1280, 
 1024*768 and 768*1024.


Yep, you are one of that 5%.


 Widescreen is for movies...


No.


 Besides, many programmers with wide screen does not have 
 multiple monitors,


Many programmers do not have. But other many programmers have.
I use multiple monitors, 16:9 and 4:3. All studios, where I 
worked, uses multiple monitors. Most part of professional 
developers, who I personally know, uses multiple monitors.
So, this is not an argument.


 so they need space both for website and editor on same screen.


Firstly, in most cases it will be D documentation. And it anyway 
will use left-side menu.
And second - current design already support small width.
Dec 22 2015
next sibling parent reply Charles <csmith.ku2013 gmail.com> writes:
On Tuesday, 22 December 2015 at 08:52:28 UTC, Dmitry wrote:

 On Tuesday, 22 December 2015 at 08:04:29 UTC, Ola Fosheim 
 Grøstad wrote:

 I use exclusively 4:3 and 3:4, 1600*1280, 1280*1024, 
 1024*1280, 1024*768 and 768*1024.


 Yep, you are one of that 5%.


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.

The reason web designers have a strong preference towards tall 
sites vs wide sites is twofold. Firstly, its hard to collect 
meaningful statistics on their own users, because browser 
dimensions might be set based on the existing site design. 
Secondly they need to design for mobile screens anyways, because 
request headers suggest they account for over 50% of internet 
users. That said, that's something that should also be 
specifically checked per website.


 Widescreen is for movies...


 No.


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.


 Besides, many programmers with wide screen does not have 
 multiple monitors,


 Many programmers do not have. But other many programmers have.
 I use multiple monitors, 16:9 and 4:3. All studios, where I 
 worked, uses multiple monitors. Most part of professional 
 developers, who I personally know, uses multiple monitors.
 So, this is not an argument.


Again, I agree with the sentiment, but anecdotal evidence isn't a 
legitimate argument to block design changes. Example anecdotal 
counter-argument: Even though I have 3 x widescreen monitors, I 
generally only have any one web page on a sixth of my total 
screen space, which favors a narrow format.


 so they need space both for website and editor on same screen.


 Firstly, in most cases it will be D documentation. And it 
 anyway will use left-side menu.
 And second - current design already support small width.


To be fair, D's documentation uses a left-side menu, but it 
removes the top level navigation (you have to press the logo). 
I'd call that more of a design flaw than a feature.
Dec 22 2015
parent reply Dmitry <dmitry indiedev.ru> writes:
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?
2) Do you think that dlang.org statisitcs will be very different 
with world statistics? I don't think so.
3) Do you think that % of 4:3 displays will not drop? In all 
world it decrease each month.

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%

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.


 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.


 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.


 I'd call that more of a design flaw than a feature.


Do you have more good ideas?
Dec 22 2015
next sibling parent anonymous <anonymous example.com> writes:
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.
Dec 22 2015
prev sibling parent Charles <csmith.ku2013 gmail.com> writes:
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.
Dec 22 2015
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 22 December 2015 at 08:52:28 UTC, Dmitry wrote:

 Yep, you are one of that 5%.


Me too.


 Many programmers do not have. But other many programmers have.
 I use multiple monitors, 16:9 and 4:3. All studios, where I 
 worked, uses multiple monitors. Most part of professional 
 developers, who I personally know, uses multiple monitors.
 So, this is not an argument.


While I have a second monitor, I very rarely use it (and when I 
do, it is more for youtube than documentation).


I also very rarely keep websites maximized. I like to resize the 
window so I can see it and the other stuff I want at the same 
time. So while my screen might be 1280, my browser window often 
isn't.... and a good web design should work in all these cases.
Dec 22 2015
parent reply Dmitry <dmitry indiedev.ru> writes:
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.
Dec 22 2015
next sibling parent anonymous <anonymous example.com> writes:
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.
Dec 22 2015
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.
Dec 22 2015
prev sibling next sibling parent crimaniak <crimaniak gmail.com> writes:
Most of the audience of the site can be roughly divided into two 
categories: beginners and experienced users of D.
for beginners:
Looking to this sketch I think it will be useful to add some 
simple installation instruction for detected user's OS right here 
(to appreciate the complexity of the D installation before 
clicking), highlight links to Learn forum and IRC channel as most 
useful places to resolve problems and make documentation more 
accessible (btw, try link like http://php.net/preg_replace for 
example - I want to use dlang.org/Tuple and so on). It will be 
useful also to provide selector of online examples to allow 
beginners to see most interesting examples. Now if I want to see 
another example I need to reload page.
for experienced:
Many of existing blocks like "Why D?", "Learn", online examples 
are irrelevant to experienced D programmer. May be make switch 
button to drop out all presentation stuff and leave only more 
details docs and news sections? Or may be separate page.
Dec 30 2015
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Saturday, 19 December 2015 at 14:33:35 UTC, Jacob Carlborg 
wrote:

 [1] 
 http://forum.dlang.org/thread/ejpuwwlutklvlozyfnqy forum.dlang.org
 [2] 
 http://forum.dlang.org/thread/fdbnecqbemseocwzghxw forum.dlang.org
 [3] http://www.googledrive.com/host/0B7UtafxGD9vESlB3aFBxcjNPOXM


This reminded me when at work we got new design in html/css and 
had to put it on the site. It looked better but lacked 1/3 of 
fields and functionality. Then backend developers had to fix 
design and in the end it was better than before but not as good 
as html/css from designer.

I think its a good start, but needs some layout changes. IMHO 
"Why D?" should be almost at the top or near code sample. I will 
meditate on it.
Jan 06 2016
parent reply anonymous <anonymous example.com> writes:
On 06.01.2016 09:00, welkam wrote:

 This reminded me when at work we got new design in html/css and had to
 put it on the site. It looked better but lacked 1/3 of fields and
 functionality. Then backend developers had to fix design and in the end
 it was better than before but not as good as html/css from designer.


Also check out http://d-ag0aep6g.rhcloud.com/ where I'm currently 
working on the implementation. It's a little different from the mockup, 
precisely because I'm trying not to drop features/content.
Jan 06 2016
next sibling parent welkam <wwwelkam gmail.com> writes:
On Wednesday, 6 January 2016 at 11:35:12 UTC, anonymous wrote:

 Also check out http://d-ag0aep6g.rhcloud.com/ where I'm 
 currently working on the implementation. It's a little 
 different from the mockup, precisely because I'm trying not to 
 drop features/content.


I am aware of your work. I will finish my "meditation" tomorrow 
and let you know
Jan 06 2016
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Wednesday, 6 January 2016 at 11:35:12 UTC, anonymous wrote:

 Also check out http://d-ag0aep6g.rhcloud.com/


It is improving!

About the "Your code here" box: I accidentally had your page and 
dlang.org side-by-side with the same "Round floating point 
numbers" example, only yours had the inline comments stripped. I 
think the comments add a lot of value, and would advise to leave 
them in. I know this design looks bad when that box gets too 
high, and I think we would need a solution that allows examples 
with more lines without the length of the example affecting the 
layout of the page. Here are a few ideas (without knowing whether 
they would be doable or not):

   1. Box with fixed height and a slider to scroll the contents.
   2. Manually resizable box, much like the edit field in the 
online forums, with a slider when necessary.
   3. Box clipped to a fixed height (possibly with fade-out effect 
at the bottom). It could be expanding dynamically on mouse-over. 
The buttons would probably be best to have at the top.
   4. The drop-downs in the "Why D?" section work very well. 
Similarly, the box could be clipped as in 3 and expand on click. 
Encourage clicking on it by having a big "Play" button on it as 
you see on video's -- or something similar.

I hope you'll find a practical and attractive solution.

Bastiaan.
Jan 07 2016
parent reply anonymous <anonymous example.com> writes:
On 07.01.2016 10:02, Bastiaan Veelo wrote:

 About the "Your code here" box: I accidentally had your page and
 dlang.org side-by-side with the same "Round floating point numbers"
 example, only yours had the inline comments stripped.


Yeah, I also stripped some of its functionality (processing args instead 
of stdin), and I dropped the RPN calculator example entirely, because I 
couldn't get it down to acceptable size.


 I think the
 comments add a lot of value, and would advise to leave them in. I know
 this design looks bad when that box gets too high, and I think we would
 need a solution that allows examples with more lines without the length
 of the example affecting the layout of the page. Here are a few ideas
 (without knowing whether they would be doable or not):

    1. Box with fixed height and a slider to scroll the contents.
    2. Manually resizable box, much like the edit field in the online
 forums, with a slider when necessary.
    3. Box clipped to a fixed height (possibly with fade-out effect at
 the bottom). It could be expanding dynamically on mouse-over. The
 buttons would probably be best to have at the top.
    4. The drop-downs in the "Why D?" section work very well. Similarly,
 the box could be clipped as in 3 and expand on click. Encourage clicking
 on it by having a big "Play" button on it as you see on video's -- or
 something similar.


Thanks, the idea of making the example expandable somehow didn't occur 
to me.

However, my stance at the moment is that the intro examples should just 
be really short. The message is that you can do something useful or cool 
in just a couple lines of code. That means outright rejection of 
anything longer than, say, 20 lines, or maybe even just 15.
Jan 07 2016
next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:

 However, my stance at the moment is that the intro examples 
 should just be really short. The message is that you can do 
 something useful or cool in just a couple lines of code. That 
 means outright rejection of anything longer than, say, 20 
 lines, or maybe even just 15.


Understand. But IMO the main objective should be to demonstrate 
expressiveness and productivity to newcomers, and therefore it is 
crucial that the examples are understandable in its entirety by 
every newbie. Someone unfamiliar to D's UFCS and template 
instantiation syntax are likely unable to parse these examples in 
their heads without explanatory comments. Without the comments 
this example reduces to an incomprehensible blob of code without 
structure (in the eyes of a first-time visitor, who may not have 
a degree in CS) and is likely to repel instead of attract. This 
looks pretty frightening if the objective is just to round 
floating point numbers (as explained by the only remaining 
comment) -- of course we know that this does a lot more, but a 
newbie doesn't.

A competition for writing the most concise code does not 
necessarily produce the most illustrative introductions into a 
language.

Bastiaan.
Jan 07 2016
parent anonymous <anonymous example.com> writes:
On 07.01.2016 12:36, Bastiaan Veelo wrote:

 Understand. But IMO the main objective should be to demonstrate
 expressiveness and productivity to newcomers, and therefore it is
 crucial that the examples are understandable in its entirety by every
 newbie. Someone unfamiliar to D's UFCS and template instantiation syntax
 are likely unable to parse these examples in their heads without
 explanatory comments. Without the comments this example reduces to an
 incomprehensible blob of code without structure (in the eyes of a
 first-time visitor, who may not have a degree in CS) and is likely to
 repel instead of attract.


I don't agree that examples need to be fully understandable to newbies. 
We'd have to explain every single line. Rather, I think the examples 
should answer the question "How familiar or outlandish will D be for me?"

That said, I'm not against comments, and I may have gone overboard when 
cutting that example down. But I still think it's too long with all 
comments intact.


 This looks pretty frightening if the objective
 is just to round floating point numbers (as explained by the only
 remaining comment) -- of course we know that this does a lot more, but a
 newbie doesn't.


Maybe the example should focus on command line arguments instead of 
stdin. No "replace anything that looks like a number", which is hard to 
match properly anyway, but instead just assume numbers in args. No regex 
necessary, just a `.map!(arg => arg.to!real.round.to!string)`.

Unfortunately, it looks like the handling of command line args is broken 
on dpaste: https://issues.dlang.org/show_bug.cgi?id=15050


 A competition for writing the most concise code does not necessarily
 produce the most illustrative introductions into a language.


It's not a competition to write the shortest, but a competition to come 
up with something that's short enough. While being short it should 
actually be properly formatted, idiomatic D code.
Jan 07 2016
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:

 Yeah, I also stripped some of its functionality (processing 
 args instead of stdin),


I sometimes use this box to quickly test something. Although I 
have never had a use for args, I might in the future. I found it 
was nice to see that it could do that.
Jan 07 2016
parent anonymous <anonymous example.com> writes:
On 07.01.2016 12:49, Bastiaan Veelo wrote:

 On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:

 Yeah, I also stripped some of its functionality (processing args
 instead of stdin),


 I sometimes use this box to quickly test something. Although I have
 never had a use for args, I might in the future. I found it was nice to
 see that it could do that.


I didn't cut the args functionality from the code box, just from that 
one example.
Jan 07 2016
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:

 However, my stance at the moment is that the intro examples 
 should just be really short. The message is that you can do 
 something useful or cool in just a couple lines of code. That 
 means outright rejection of anything longer than, say, 20 
 lines, or maybe even just 15.


Or put longer examples behind "Learn more" button.
Jan 07 2016
parent anonymous <anonymous example.com> writes:
On 07.01.2016 16:36, welkam wrote:

 On Thursday, 7 January 2016 at 10:58:49 UTC, anonymous wrote:

 However, my stance at the moment is that the intro examples should
 just be really short. The message is that you can do something useful
 or cool in just a couple lines of code. That means outright rejection
 of anything longer than, say, 20 lines, or maybe even just 15.


 Or put longer examples behind "Learn more" button.


Totally. A page with longer, explained examples would be great. We do 
have some longer examples in the "Why D?" section at the bottom, so 
maybe a "see more examples below" link would work for now.
Jan 07 2016
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 6 January 2016 at 11:35:12 UTC, anonymous wrote:

 Also check out http://d-ag0aep6g.rhcloud.com/ where I'm 
 currently working on the implementation. It's a little 
 different from the mockup, precisely because I'm trying not to 
 drop features/content.


So I meditated and came to conclusion that there is too much text 
and I didnt find any way of laying it in this new design that 
would be a nice sales pitch. D is big (thats what she said) and 
there is a lots to talk about, but people want TL;DR version.

On the other hand changing "why D" section requires more work and 
we lack spare hands.

in http://d-ag0aep6g.rhcloud.com/

comunity, learn, documentation and packages are redundant. They 
either should be in meniu or not on front page. And if there are 
redundant links they should be in footer.

Now documentation.

anonymous:http://d-ag0aep6g.rhcloud.com/phobos/std_algorithm_iteration.html

Me playing around: 
https://drive.google.com/file/d/0B6ofJyypw1tGa29aTGNVQVJQcVk/view?usp=sharing

Open them both and just look at them for 10 sec. Dont scroll 
because I put 0 work after License:. Just look at them and write 
which one has bigger strain on you eyes.

IMHO everyone who is working on improving website should get on 
skype or hangouts and make a plan. Now Ivan made new design for 
documentation, anonymous also put some work, Adam is cooking 
something up. I smell lots of redundant work ahead
Jan 07 2016
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-07 16:33, welkam wrote:


 in http://d-ag0aep6g.rhcloud.com/


I noticed that the buttons for the example cover the drop down menu for 
Resources, if it's open.

-- 
/Jacob Carlborg
Jan 07 2016
parent anonymous <anonymous example.com> writes:
On 07.01.2016 16:55, Jacob Carlborg wrote:

 I noticed that the buttons for the example cover the drop down menu for
 Resources, if it's open.


Fixed, thanks.
Jan 07 2016
prev sibling parent anonymous <anonymous example.com> writes:
On 07.01.2016 16:33, welkam wrote:

 in http://d-ag0aep6g.rhcloud.com/

 comunity, learn, documentation and packages are redundant. They either
 should be in meniu or not on front page. And if there are redundant
 links they should be in footer.


I'm not sure if redundancy is to be avoided here. I think the redesign 
took a lot of inspiration from <http://ocaml.org> which has the same 
preview snippets of the different site sections. Personally I could do 
without them, and I wouldn't mind if we decide against them, but a 
little tour around the site and direct links to the interesting parts 
may help people find what they're looking for.


 Now documentation.

 anonymous:http://d-ag0aep6g.rhcloud.com/phobos/std_algorithm_iteration.html

 Me playing around:
 https://drive.google.com/file/d/0B6ofJyypw1tGa29aTGNVQVJQcVk/view?usp=sharing


 Open them both and just look at them for 10 sec. Dont scroll because I
 put 0 work after License:. Just look at them and write which one has
 bigger strain on you eyes.


I'm not sure what you want me to notice. Differences I see:

* different shade of red throughout,
* heading is red,
* no "Jump to" links,
* links are not underlined,
* less horizontal lines on the table.

Regarding the specific shade of red: I don't really care about any exact 
colors. I'm not usually doing visual design, and my monitor is not 
properly calibrated.

Re the red heading: I'm against coloring unclickable stuff the same as 
clickable stuff. I'm guilty of doing this with the signature boxes: the 
red border on the left and the documented symbol are red but not 
clickable. I took that from the mockup, but I don't like it. If the 
point of the red heading is to lessen the contrast, I'd suggest a color 


Re link underlines: I made a pull request for un-underlined links 
before. The argument that made me abandon the idea was that it makes 
things harder for color blind people. Note that already links are not 
underlined in navigation areas where it's supposedly obvious that 
they're clickable.

Re the jump links: I'm not sure if this is a deliberate change of yours, 
or maybe it's just a problem with the JS. If it's deliberate, the 
paragraph below applies.

Re the table lines: I didn't touch those. They're the same in my version 
as on the current dlang.org. Generally, I'd like to leave improvements 
that are independent of the redesign out of it.

If I'm missing anything you'll have to spell it out for me.


 IMHO everyone who is working on improving website should get on skype or
 hangouts and make a plan. Now Ivan made new design for documentation,
 anonymous also put some work, Adam is cooking something up. I smell lots
 of redundant work ahead


Aside from general visuals, I'm deliberately leaving Ivan's ideas for 
the phobos docs out for now. Exactly because there's some turmoil in the 
area. And because I want to wrap this up sometime soon. I think Adam's 
work is pretty much independent from mine here.
Jan 07 2016