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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 other than red, maybe just some grey that's less dark than #333. 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