www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Redesign of dlang.org

reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
Hello,

I've been D enthusiast for couple of years now (but I do not 
participate much in discussions here, although I read forums 
almost daily), and I keep telling people about D and how awesome 
it is.

But, all this time D's official website somehow archaic look kept 
troubling me. It reminds me of early 2000's design and I really 
cannot associate this design with "modern" or "elegant", what D 
really is.
I think that we must invest time and energy improving the 
website's look and feel as that is what people first coming to D 
will see. We need to strive for "wow" and not "meh" as a first 
impression.

So I have started this thread to see if there is a chance for 
complete redesign of dlang.org.

I have also tried to design something myself (although I'm not a 
designer) and this is what I came up with:

http://krcko.net/dlang.org/dlang-home-draft1.png

I'm not entirely satisfied with it but I believe that it looks 
better (or at least more modern) than the current design.


So, what do you guys think?




-- Aleksandar
Apr 18 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic  
<aleksandar ruzicic.info> wrote:


 Hello,

 I've been D enthusiast for couple of years now (but I do not participate  
 much in discussions here, although I read forums almost daily), and I  
 keep telling people about D and how awesome it is.


Great!


 But, all this time D's official website somehow archaic look kept  
 troubling me. It reminds me of early 2000's design and I really cannot  
 associate this design with "modern" or "elegant", what D really is.
 I think that we must invest time and energy improving the website's look  
 and feel as that is what people first coming to D will see. We need to  
 strive for "wow" and not "meh" as a first impression.

 So I have started this thread to see if there is a chance for complete  
 redesign of dlang.org.

 I have also tried to design something myself (although I'm not a  
 designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks better  
 (or at least more modern) than the current design.


 So, what do you guys think?


To be honest, it looks no "better" than the current website. Basically  
it's more windows-8-ish. But I don't think it's a significant improvement.  
BTW, I don't think you properly remember early 2000's web sites...

I don't share your opinion that the web site need to be "modern" to avoid  
warding off potential adopters. If they are turned off of using a system  
programming language by a bland (debatable) site look and feel, then I  
think there was really something else bothering them.

That being said, changing look and feel has a "this site is being  
maintained" air to it. I just don't think it's critical enough at this  
point to diverge talent away from working on the language.

-Steve
Apr 18 2014
next sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 4/18/14, 7:22 AM, Steven Schveighoffer wrote:

 On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic
 <aleksandar ruzicic.info> wrote:


 Hello,

 I've been D enthusiast for couple of years now (but I do not
 participate much in discussions here, although I read forums almost
 daily), and I keep telling people about D and how awesome it is.


 Great!


 But, all this time D's official website somehow archaic look kept
 troubling me. It reminds me of early 2000's design and I really cannot
 associate this design with "modern" or "elegant", what D really is.
 I think that we must invest time and energy improving the website's
 look and feel as that is what people first coming to D will see. We
 need to strive for "wow" and not "meh" as a first impression.

 So I have started this thread to see if there is a chance for complete
 redesign of dlang.org.

 I have also tried to design something myself (although I'm not a
 designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks better
 (or at least more modern) than the current design.


 So, what do you guys think?


 To be honest, it looks no "better" than the current website. Basically
 it's more windows-8-ish. But I don't think it's a significant
 improvement. BTW, I don't think you properly remember early 2000's web
 sites...

 I don't share your opinion that the web site need to be "modern" to
 avoid warding off potential adopters. If they are turned off of using a
 system programming language by a bland (debatable) site look and feel,
 then I think there was really something else bothering them.

 That being said, changing look and feel has a "this site is being
 maintained" air to it. I just don't think it's critical enough at this
 point to diverge talent away from working on the language.

 -Steve


As the guy who was mostly responsible for the current look and feel of 
the website I can provide some insight into the effort required. The 
website is built using DDoc[1], and anyone who wants to change the look 
and feel will need to learn it. It's not difficult. It does mean that 
the site is static HTML, so any dynamism needs to be JS-only (and I 
think any efforts to make the pages largely JS-driven would meet 
resistance).

What was a little weird was trying to use DDoc to expand" the navigation 
tree when you're on a subpage of a main category. The original website 
listed every single page in the sidebar, which made the sidebar 
extremely unwieldy. Due to DDoc limitations I ended up having to put a 
CATEGORY_FOO macro in each page in the site, where the FOO is one of the 
categories in the sidebar. You may be able to figure out a better way. 
Just fork the site on github[2] and experiment!

Also note that there's a movement to make at least part of the website 
(the Phobos docs) use a different documentation generator, so the new 
look would need to be ported to that too. I suspect that wouldn't be hard.

Be aware that the current Tweets sidebar on the main page may be hard to 
get rid of; I noticed it wasn't in your mockup :)

Based on the last go-around there would be some work required from 
Walter and Andrei, but assuming you're implementing the new look and 
feel then their work would be mostly related to pushing changes to a 
beta site and then to the main site. They can probably speak better to 
the amount of effort they'd need to put in. If you're not doing the work 
of implementing the new look and feel then I suspect this proposal is 
dead on arrival unless someone else steps up to help.

Finally I like your look; I think it would be worth refining and 
pursuing. I make no claim to be a graphic designer and I'm certainly not 
offended by any criticism of the current look; at the time I had two 
goals; 1) look better than the previous site at digitalmars.com and 2) 
tame the massive sidebar into something more reasonable. I think they 
both succeeded but I'm very aware that things can look better.

[1] http://dlang.org/ddoc.html
[2] https://github.com/D-Programming-Language/dlang.org
Apr 18 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/18/14, 8:30 AM, David Gileadi wrote:

 It does mean that the site is static HTML, so any dynamism needs to be
 JS-only (and I think any efforts to make the pages largely JS-driven
 would meet resistance).


We can (and probably should) integrate server-side scripting as well. 
http://dlang.org/bugstats uses PHP. Ideally we'd migrate the entire 
website to vibe.d.

Andrei
Apr 18 2014
next sibling parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu 
wrote:

 On 4/18/14, 8:30 AM, David Gileadi wrote:

 It does mean that the site is static HTML, so any dynamism 
 needs to be
 JS-only (and I think any efforts to make the pages largely 
 JS-driven
 would meet resistance).


 We can (and probably should) integrate server-side scripting as 
 well. http://dlang.org/bugstats uses PHP. Ideally we'd migrate 
 the entire website to vibe.d.

 Andrei


I think that having vibe.d behind dlang.org would be great!
Apr 18 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu 
wrote:

 On 4/18/14, 8:30 AM, David Gileadi wrote:

 It does mean that the site is static HTML, so any dynamism 
 needs to be
 JS-only (and I think any efforts to make the pages largely 
 JS-driven
 would meet resistance).


 We can (and probably should) integrate server-side scripting as 
 well. http://dlang.org/bugstats uses PHP. Ideally we'd migrate 
 the entire website to vibe.d.

 Andrei


I assume moving from DDoc to something like Vibe'd's Jade 
templates isn't on the table (for reasons such as losing the spec 
ebook generation and others). The only advantage I can think of 
with moving to vibe.d is if ddox were used for the entire site 
and would manage the regeneration of pages automatically, pulling 
from github itself. Then any pull request that a reviewer merges 
could trigger a site update.

With more frequent updates, D-P-L/dlang.org would need to 
properly use version branches to avoid having prerelease changes 
but that's a change that's been needed for a long time. I'm not 
sure if ddox was intended for something like this though (static 
pages, as opposed to just documentation generation). Sönke would 
probably have to weigh in and say if there is any real advantage 
here. Making stuff "Powered by D" is always a nice change though.
Apr 18 2014
prev sibling next sibling parent "Jacob Carlborg" <doob me.com> writes:
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu 
wrote:


 We can (and probably should) integrate server-side scripting as 
 well. http://dlang.org/bugstats uses PHP. Ideally we'd migrate 
 the entire website to vibe.d.


Yes please. Ddoc might be better than plain HTML but most other 
frameworks for doing web sites are better than Ddoc.

--
/Jacob Carlborg
Apr 19 2014
prev sibling parent "alexhairyman" <alexhairyman gmail.com> writes:
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu 
wrote:

 On 4/18/14, 8:30 AM, David Gileadi wrote:

 It does mean that the site is static HTML, so any dynamism 
 needs to be
 JS-only (and I think any efforts to make the pages largely 
 JS-driven
 would meet resistance).


 We can (and probably should) integrate server-side scripting as 
 well. http://dlang.org/bugstats uses PHP. Ideally we'd migrate 
 the entire website to vibe.d.

 Andrei


Going the vibe.d route would be great for advertising D as an all 
encompassing language.
Apr 21 2014
prev sibling parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:

 As the guy who was mostly responsible for the current look and 
 feel of the website I can provide some insight into the effort 
 required. The website is built using DDoc[1], and anyone who 
 wants to change the look and feel will need to learn it. It's 
 not difficult. It does mean that the site is static HTML, so 
 any dynamism needs to be JS-only (and I think any efforts to 
 make the pages largely JS-driven would meet resistance).


I know about DDoc usage, I already know it and using it, so that 
wouldn't be the issue.
Regarding the dynamism, I would definitely go with some 
JavaScript for
the search feature (I want to provide real-time 
filtering/suggestions something like DevDocs[1]) but I would make 
it optional (so that search is still usable with JS 
disabled/unavailable).



 What was a little weird was trying to use DDoc to expand" the 
 navigation tree when you're on a subpage of a main category. 
 The original website listed every single page in the sidebar, 
 which made the sidebar extremely unwieldy. Due to DDoc 
 limitations I ended up having to put a CATEGORY_FOO macro in 
 each page in the site, where the FOO is one of the categories 
 in the sidebar. You may be able to figure out a better way. 
 Just fork the site on github[2] and experiment!


Ahh I remember that lengthy sidebar, kudos for fixing it!


 Also note that there's a movement to make at least part of the 
 website (the Phobos docs) use a different documentation 
 generator, so the new look would need to be ported to that too. 
 I suspect that wouldn't be hard.


I wasn't aware of that, do you by any chance have links to those 
threads?


 Be aware that the current Tweets sidebar on the main page may 
 be hard to get rid of; I noticed it wasn't in your mockup :)


Yeah, I've forgot about that (I'm using extensions to disable ads 
and those "social" boxes so I forgot that thing exists).


 Based on the last go-around there would be some work required 
 from Walter and Andrei, but assuming you're implementing the 
 new look and feel then their work would be mostly related to 
 pushing changes to a beta site and then to the main site. They 
 can probably speak better to the amount of effort they'd need 
 to put in. If you're not doing the work of implementing the new 
 look and feel then I suspect this proposal is dead on arrival 
 unless someone else steps up to help.


Yep, I'm planning of implementing new look and feel myself.
Of course any help would be very appreciated!



 Finally I like your look; I think it would be worth refining 
 and pursuing. I make no claim to be a graphic designer and I'm 
 certainly not offended by any criticism of the current look; at 
 the time I had two goals; 1) look better than the previous site 
 at digitalmars.com and 2) tame the massive sidebar into 
 something more reasonable. I think they both succeeded but I'm 
 very aware that things can look better.


Thanks! It is just a mockup I made in an hour or so, I would like
to have some real designer(s) involved in this to make it really 
better.

The current design is waaay better than what we had before and I 
thank you
on that! That change was really refreshing.
I just think that we should keep pushing forward. And I would 
also like if
you could be able to join me in a new redesign (if it gets 
approval), at least
in a consulting role. :)


[1] http://devdocs.io/
Apr 18 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 18 April 2014 at 16:25:10 UTC, Aleksandar Ruzicic 
wrote:

 On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:

 As the guy who was mostly responsible for the current look and 
 feel of the website I can provide some insight into the effort 
 required. The website is built using DDoc[1], and anyone who 
 wants to change the look and feel will need to learn it. It's 
 not difficult. It does mean that the site is static HTML, so 
 any dynamism needs to be JS-only (and I think any efforts to 
 make the pages largely JS-driven would meet resistance).


 I know about DDoc usage, I already know it and using it, so 
 that wouldn't be the issue.
 Regarding the dynamism, I would definitely go with some 
 JavaScript for
 the search feature (I want to provide real-time 
 filtering/suggestions something like DevDocs[1]) but I would 
 make it optional (so that search is still usable with JS 
 disabled/unavailable).


Phew...you narrowly avoided a Nick/Teoh JS rant there :P.


 Also note that there's a movement to make at least part of the 
 website (the Phobos docs) use a different documentation 
 generator, so the new look would need to be ported to that 
 too. I suspect that wouldn't be hard.


 I wasn't aware of that, do you by any chance have links to 
 those threads?


Here's one (they are kind of hard to Google now that the preview 
is up on the site and "ddox" appears on every page):
http://forum.dlang.org/thread/lfjcfm$2frn$1 digitalmars.com
Apr 18 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:51:44 UTC, Brad Anderson wrote:

 Here's one (they are kind of hard to Google now that the 
 preview is up on the site and "ddox" appears on every page):
 http://forum.dlang.org/thread/lfjcfm$2frn$1 digitalmars.com


Thanks! I haven't worked with ddox yet but I'm looking forward to 
try it out, it sure looks better than ddoc-based one.
Apr 18 2014
prev sibling parent reply David Gileadi <gileadis NSPMgmail.com> writes:
On 4/18/14, 9:25 AM, Aleksandar Ruzicic wrote:

 On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:


[snip]


 Also note that there's a movement to make at least part of the website
 (the Phobos docs) use a different documentation generator, so the new
 look would need to be ported to that too. I suspect that wouldn't be
 hard.


 I wasn't aware of that, do you by any chance have links to those threads?


I'm having trouble finding the thread, but I think the idea was to use 
vibe.d's ddox[1]. There's a preview of it live at the "Preview new 
Layout" link at dlang.org. Folks, please correct me if I got this wrong 
and that preview is not powered by ddox.

[snip]


 Finally I like your look; I think it would be worth refining and
 pursuing. I make no claim to be a graphic designer and I'm certainly
 not offended by any criticism of the current look; at the time I had
 two goals; 1) look better than the previous site at digitalmars.com
 and 2) tame the massive sidebar into something more reasonable. I
 think they both succeeded but I'm very aware that things can look better.


 Thanks! It is just a mockup I made in an hour or so, I would like
 to have some real designer(s) involved in this to make it really better.


If you have access to real designers (as you mentioned in another 
message) that would be fantastic. I think the mockup you created is 
already a good direction but folks with experience in UX, typography, 
responsive design etc. could probably make dlang.org properly great.


 The current design is waaay better than what we had before and I thank you
 on that! That change was really refreshing.
 I just think that we should keep pushing forward. And I would also like if
 you could be able to join me in a new redesign (if it gets approval), at
 least
 in a consulting role. :)


I'd be happy to help. My time is more divided nowadays but I'm sure I 
can put some time into this. While we're at it some good mobile support 
would be awesome too.


 [1] http://devdocs.io/


[1] https://github.com/rejectedsoftware/ddox
Apr 18 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:55:03 UTC, David Gileadi wrote:

 If you have access to real designers (as you mentioned in 
 another message) that would be fantastic. I think the mockup 
 you created is already a good direction but folks with 
 experience in UX, typography, responsive design etc. could 
 probably make dlang.org properly great.


I just need to motivate them somehow. Designers are a bit strange 
bunch :)


 I'd be happy to help. My time is more divided nowadays but I'm 
 sure I can put some time into this. While we're at it some good 
 mobile support would be awesome too.


Excellent!

And responsive design which scales well from desktops to tablets 
and phones is a must (with support for hdpi screens of course).
Apr 18 2014
prev sibling next sibling parent Aleksandar Ruzicic <aleksandar ruzicic.info> writes:
 To be honest, it looks no "better" than the current website. Basically
 it's more windows-8-ish. But I don't think it's a significant improvement.


I agree that it's not a significant improvement. As I've said I'm not a
designer,
this was just a try to get something more appealing than the current design.
But I work every day with excellent designers and I was thinking of contacting
some
of them to iron out design, if I get approval from the community for such
endeavor.

BTW there is a reason why modern operating systems (Windows 8, iOS 7) are going
for flat
design. It's much easier to see content when there are no distractions like
radial gradients
in background, inner/outer shadows and other things that help create 3D effect
for various page components.

That being said, I do not think that current dlang.org design is not easy to
read. It is, but I would still
like to see typography improvements to make it even better.



 BTW, I don't think you properly remember early 2000's web sites...


Ok, maybe not early-early 2000's but I've begun fiddling with frontend
(HTML/CSS/JS)
in 2005 and the then-modern website look meant gradients, drop shadows and big
glossy logos.
I've built few such websites so I think I know a thing or two about that era. :)



 I don't share your opinion that the web site need to be "modern" to avoid
 warding off potential adopters. If they are turned off of using a system
 programming language by a bland (debatable) site look and feel, then I
 think there was really something else bothering them.


Understood. But I believe that better design could improve presentation of D
features.

Design should be a means to make content stand out and easy to grasp, and not
to stand
in a way ("content is the king" as some would say).

And I think that current design stands in a way, especially on the Phobos pages.
Even with the recent improvements by Andrei and others it still is hard to read
and navigate.
I think that we can do it better, but only if we would start with a complete
redesign, not just
by tweaking the look of documentation pages.



 That being said, changing look and feel has a "this site is being
 maintained" air to it. I just don't think it's critical enough at this
 point to diverge talent away from working on the language.

 -Steve


The reason I've started this thread is because I'm willing to start working on
this.
I would definitely need some guidance from the community but I don't think that
it will
result in divergence of talent.



-- Aleksandar
Apr 18 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 18 April 2014 15:22, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic
 <aleksandar ruzicic.info> wrote:


 Hello,

 I've been D enthusiast for couple of years now (but I do not participate
 much in discussions here, although I read forums almost daily), and I keep
 telling people about D and how awesome it is.



 Great!



 But, all this time D's official website somehow archaic look kept
 troubling me. It reminds me of early 2000's design and I really cannot
 associate this design with "modern" or "elegant", what D really is.
 I think that we must invest time and energy improving the website's look
 and feel as that is what people first coming to D will see. We need to
 strive for "wow" and not "meh" as a first impression.

 So I have started this thread to see if there is a chance for complete
 redesign of dlang.org.

 I have also tried to design something myself (although I'm not a designer)
 and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks better (or
 at least more modern) than the current design.


 So, what do you guys think?



 To be honest, it looks no "better" than the current website. Basically it's
 more windows-8-ish. But I don't think it's a significant improvement. BTW, I
 don't think you properly remember early 2000's web sites...


Really?  To me it looks like the OP is mimicking Github dccumentation pages.

eg: http://uwsgi-docs.readthedocs.org/en/latest/
Apr 18 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 17:20:55 UTC, Iain Buclaw via 
Digitalmars-d wrote:

 Really?  To me it looks like the OP is mimicking Github 
 dccumentation pages.

 eg: http://uwsgi-docs.readthedocs.org/en/latest/


I really like the look of Read the Docs and it's something I 
would definitely base design of documentation pages on (which are 
the most important, in my opinion).

But that mockup of homepage is not directly inspired by (or 
trying to mimic) any website. I've just opened Photoshop chose 
base colors and made layout that felt natural to me.
Apr 18 2014
prev sibling parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer 
wrote:

 I don't share your opinion that the web site need to be 
 "modern" to avoid warding off potential adopters. If they are 
 turned off of using a system programming language by a bland 
 (debatable) site look and feel, then I think there was really 
 something else bothering them.


Case in point: http://gcc.gnu.org/
Apr 19 2014
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 Apr 2014 13:00, "Lars T. Kyllingstad via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer wrote:

 I don't share your opinion that the web site need to be "modern" to




avoid warding off potential adopters. If they are turned off of using a
system programming language by a bland (debatable) site look and feel, then
I think there was really something else bothering them.

 Case in point: http://gcc.gnu.org/


What's wrong with that site? Everything is clear to find and readable.
Apr 20 2014
parent "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 20 April 2014 at 08:38:25 UTC, Iain Buclaw via 
Digitalmars-d wrote:

 On 19 Apr 2014 13:00, "Lars T. Kyllingstad via Digitalmars-d" <
 digitalmars-d puremagic.com> wrote:

 On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer 
 wrote:

 I don't share your opinion that the web site need to be 
 "modern" to




 avoid warding off potential adopters. If they are turned off of 
 using a
 system programming language by a bland (debatable) site look 
 and feel, then
 I think there was really something else bothering them.

 Case in point: http://gcc.gnu.org/


 What's wrong with that site? Everything is clear to find and 
 readable.


There's nothing wrong with it at all!  I was agreeing with Steve, 
not arguing against him.  My point was that even though GCC is 
one of the most popular software development tools in the world, 
their site, like most of gnu.org, looks a bit... old school.  
Which is just fine. :)
Apr 20 2014
prev sibling next sibling parent "Christof Schardt" <Christof Schardt.info> writes:
"Aleksandar Ruzicic" <aleksandar ruzicic.info> schrieb im Newsbeitrag 
news:mmoxalewsvwcgeaasvri forum.dlang.org...


 But, all this time D's official website somehow archaic look kept 
 troubling me.


Me too.


 I have also tried to design something myself (although I'm not a designer) 
 and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks better (or 
 at least more modern) than the current design.


 So, what do you guys think?


A good start!
+1
Apr 18 2014
prev sibling next sibling parent captaindet <2krnk gmx.net> writes:
On 2014-04-18 09:04, Aleksandar Ruzicic wrote:

 So, what do you guys think?


i like it.
Apr 18 2014
prev sibling next sibling parent reply "Frustrated" <Who where.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 Hello,

 I've been D enthusiast for couple of years now (but I do not 
 participate much in discussions here, although I read forums 
 almost daily), and I keep telling people about D and how 
 awesome it is.

 But, all this time D's official website somehow archaic look 
 kept troubling me. It reminds me of early 2000's design and I 
 really cannot associate this design with "modern" or "elegant", 
 what D really is.
 I think that we must invest time and energy improving the 
 website's look and feel as that is what people first coming to 
 D will see. We need to strive for "wow" and not "meh" as a 
 first impression.

 So I have started this thread to see if there is a chance for 
 complete redesign of dlang.org.

 I have also tried to design something myself (although I'm not 
 a designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?




 -- Aleksandar


I like it too. A little cleaner/sharper. A little more balanced. 
(centered, colors, etc)

Not a huge improvement in some ways, which is good and bad. The 
question is, would the change be worth it? If it's easy to do, 
yes, if it causes problems and takes too much time to get things 
right, no.
Apr 18 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 15:55:57 UTC, Frustrated wrote:

 I like it too. A little cleaner/sharper. A little more 
 balanced. (centered, colors, etc)

 Not a huge improvement in some ways, which is good and bad. The 
 question is, would the change be worth it? If it's easy to do, 
 yes, if it causes problems and takes too much time to get 
 things right, no.


It's just first a mockup, but it's a direction in which I think 
we should go.

It would definitely take time to get both UI and (more 
importantly) UX right,
and I don't think that's a bad thing.

Current design is good enough so that redesigning it is not 
matter of urgency.
Apr 18 2014
prev sibling next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 So, what do you guys think?


I _strongly_ suggest any proposed redesign retain the 
left-justification seen in the current design.  It improves 
readability and gives opportunities for better information 
density.

I know centred, fixed-width designs are in vogue, but for a 
documentation project, I would that the gutters instead be turned 
to more useful purposes.  Like documentation.

-Wyatt
Apr 18 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:

 On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
 wrote:

 So, what do you guys think?


 I _strongly_ suggest any proposed redesign retain the 
 left-justification seen in the current design.  It improves 
 readability and gives opportunities for better information 
 density.

 I know centred, fixed-width designs are in vogue, but for a 
 documentation project, I would that the gutters instead be 
 turned to more useful purposes.  Like documentation.

 -Wyatt


I must respectfully disagree about retaining left justification.
I have 27'' monitor with resolution of 2560x1440 and left-aligned 
websites are really hard to read!

There is a reason why most editors have "zen mode" which centers 
your code on a screen. It's easier to read when it's centered and 
not too wide.

Current design has no limitation on line width which (at my 
resolution) results in ~300 characters wide lines, and it's 
really unreadable.

I would go for a maximum of 120 characters wide lines with 
content centered on larger monitors.



-- Aleksandar
Apr 18 2014
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic  
<aleksandar ruzicic.info> wrote:


 On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:

 On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote:

 So, what do you guys think?


 I _strongly_ suggest any proposed redesign retain the  
 left-justification seen in the current design.  It improves readability  
 and gives opportunities for better information density.

 I know centred, fixed-width designs are in vogue, but for a  
 documentation project, I would that the gutters instead be turned to  
 more useful purposes.  Like documentation.

 -Wyatt


 I must respectfully disagree about retaining left justification.
 I have 27'' monitor with resolution of 2560x1440 and left-aligned  
 websites are really hard to read!


Making something that works like this would be excellent:

http://forum.dlang.org/

-Steve
Apr 18 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 1:24 PM, Steven Schveighoffer wrote:

 On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic
 <aleksandar ruzicic.info> wrote:

 I must respectfully disagree about retaining left justification.
 I have 27'' monitor with resolution of 2560x1440 and left-aligned
 websites are really hard to read!


 Making something that works like this would be excellent:

 http://forum.dlang.org/


God no. I like forum.dlang.org and all, but scaling the font size when 
the window resizes is horrible UX. Example: If I shrink the browser 
window, for *whatever* reason, I expect not to have an over-zealous CSS 
decide "Oh! He must want the text to become ridiculously small! Ok!"
Apr 19 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-04-19 23:06, Nick Sabalausky wrote:


 God no. I like forum.dlang.org and all, but scaling the font size when
 the window resizes is horrible UX. Example: If I shrink the browser
 window, for *whatever* reason, I expect not to have an over-zealous CSS
 decide "Oh! He must want the text to become ridiculously small! Ok!"


I haven't noticed that until now. That truly sucks.

-- 
/Jacob Carlborg
Apr 20 2014
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 19 Apr 2014 17:06:21 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 On 4/18/2014 1:24 PM, Steven Schveighoffer wrote:

 On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic
 <aleksandar ruzicic.info> wrote:

 I must respectfully disagree about retaining left justification.
 I have 27'' monitor with resolution of 2560x1440 and left-aligned
 websites are really hard to read!


 Making something that works like this would be excellent:

 http://forum.dlang.org/


 God no. I like forum.dlang.org and all, but scaling the font size when  
 the window resizes is horrible UX. Example: If I shrink the browser  
 window, for *whatever* reason, I expect not to have an over-zealous CSS  
 decide "Oh! He must want the text to become ridiculously small! Ok!"


I like how the side-bar goes away instead of making the text column  
uselessly small.

The font shrinking is slightly off-putting, but I think having the font  
grow when the window is expanded is somewhat useful. To be sure, the last  
level of font shrinkage could be done away with.

But I agree with Aleksandar, that having the text in a window expand as  
far as my very-wide monitor will go, is not helpful. Things are hard to  
read when they get too long.

-Steve
Apr 21 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/21/2014 8:14 AM, Steven Schveighoffer wrote:

 but I think having the font
 grow when the window is expanded is somewhat useful.


I don't. Overly-large text is just as hard to read as overly-small text.

In any case, if I want the text bigger/smaller, that's what the 
zoom/text-size settings are for (unless I'm unlucky enough to be using a 
mobile browser, which all moronically obey CSS's PUOs. PUO: Not just for 
badly-authored DVDs anymore. Thanks, W3C asshats!!)


 But I agree with Aleksandar, that having the text in a window expand as
 far as my very-wide monitor will go, is not helpful. Things are hard to
 read when they get too long.


Yea, I agree too. Luckily that's what max-width is for...although that 
really SHOULD'VE been a browser setting/feature, not a per-page CSS 
feature. But then, the browser developers these days will cram anything 
and everything into CSS/HTML anymore (except, of course, anything that 
actually gives the *user* any control over anything :/ )
Apr 21 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 21 April 2014 at 22:35:32 UTC, Nick Sabalausky wrote:

 setting/feature, not a per-page CSS feature. But then, the 
 browser developers these days will cram anything and everything 
 into CSS/HTML anymore (except, of course, anything that 
 actually gives the *user* any control over anything :/ )


Then again, most users don't even know that there is a search 
function built into the browser… so they probably don'
Apr 21 2014
prev sibling next sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
wrote:

 On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:

 On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
 wrote:

 So, what do you guys think?


 I _strongly_ suggest any proposed redesign retain the 
 left-justification seen in the current design.  It improves 
 readability and gives opportunities for better information 
 density.

 I know centred, fixed-width designs are in vogue, but for a 
 documentation project, I would that the gutters instead be 
 turned to more useful purposes.  Like documentation.

 -Wyatt


 I must respectfully disagree about retaining left justification.
 I have 27'' monitor with resolution of 2560x1440 and 
 left-aligned websites are really hard to read!

 There is a reason why most editors have "zen mode" which 
 centers your code on a screen. It's easier to read when it's 
 centered and not too wide.

 Current design has no limitation on line width which (at my 
 resolution) results in ~300 characters wide lines, and it's 
 really unreadable.

 I would go for a maximum of 120 characters wide lines with 
 content centered on larger monitors.



 -- Aleksandar


Or just a little switch in a corner somewhere to change the 
justification, with a cookie.
Apr 18 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 22:06:03 UTC, John Colvin wrote:
[snip]

 Or just a little switch in a corner somewhere to change the 
 justification, with a cookie.


That can be easily done (although I wouldn't use cookies) but I 
would prefer centered layout to be default option.
Apr 19 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 3:45 AM, Aleksandar Ruzicic wrote:

 On Friday, 18 April 2014 at 22:06:03 UTC, John Colvin wrote:
 [snip]

 Or just a little switch in a corner somewhere to change the
 justification, with a cookie.


 That can be easily done (although I wouldn't use cookies) but I would
 prefer centered layout to be default option.


(left/right/centered) Layout != (left/right/centered/justified) text 
justification

I don't think anyone's argued against the page layout itself being 
centered (as long as you don't mean to center the text itself - that 
would be one of the worst ways for text justification).
Apr 19 2014
prev sibling next sibling parent reply "Jacob Carlborg" <doob me.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
wrote:


 I must respectfully disagree about retaining left justification.
 I have 27'' monitor with resolution of 2560x1440 and 
 left-aligned websites are really hard to read!


Agree. I think we should use Bootstrap. Then we can also get a 
responsive web site for free.

--
/Jacob Carlborg
Apr 19 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 08:35:32 UTC, Jacob Carlborg wrote:

 On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
 wrote:


 I must respectfully disagree about retaining left 
 justification.
 I have 27'' monitor with resolution of 2560x1440 and 
 left-aligned websites are really hard to read!


 Agree. I think we should use Bootstrap. Then we can also get a 
 responsive web site for free.

 --
 /Jacob Carlborg


Bootstrap is great but I wouldn't use it for this project. As it 
might be difficult to work with when you don't want that 
"bootstrap style look". OTOH Zurb's Foundation framework is all 
about structure and it leaves styling up to you which is great. 
Also, I prefer Sass over LESS :)
Apr 19 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-04-19 10:54, Aleksandar Ruzicic wrote:


 Bootstrap is great but I wouldn't use it for this project. As it might
 be difficult to work with when you don't want that "bootstrap style
 look". OTOH Zurb's Foundation framework is all about structure and it
 leaves styling up to you which is great.


I haven't really tried designing a web site with Bootstrap without 
Bootstrap styles but I think you can pick what you like and only use that.


 Also, I prefer Sass over LESS :)


As a Ruby on Rails programmer, so do I. Therefore it's great that 
Bootstrap now days officially supports Sass [1]. BTW, I used Bootstrap 
with Sass long before it was officially supported, it worked great.

[1] http://getbootstrap.com/css/#sass

-- 
/Jacob Carlborg
Apr 19 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 10:23:39 UTC, Jacob Carlborg wrote:

 On 2014-04-19 10:54, Aleksandar Ruzicic wrote:


 Bootstrap is great but I wouldn't use it for this project. As 
 it might
 be difficult to work with when you don't want that "bootstrap 
 style
 look". OTOH Zurb's Foundation framework is all about structure 
 and it
 leaves styling up to you which is great.


 I haven't really tried designing a web site with Bootstrap 
 without Bootstrap styles but I think you can pick what you like 
 and only use that.


 Also, I prefer Sass over LESS :)


 As a Ruby on Rails programmer, so do I. Therefore it's great 
 that Bootstrap now days officially supports Sass [1]. BTW, I 
 used Bootstrap with Sass long before it was officially 
 supported, it worked great.

 [1] http://getbootstrap.com/css/#sass


Official Sass support for Bootstrap is news to me, thanks for 
info!

I have been using Foundation in last few projects and haven't 
played with Bootstrap in a while but when I did I had to override 
most of it's styles to achieve look I wanted (which resulted in a 
significant amount of CSS/LESS needed just to remove Bootstrap's 
styles).
I hope that things are better now..
Apr 19 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
Ok here's a mockup of search concept I would like to implement:

http://krcko.net/dlang.org/dlang-search-concept.png

Search suggestions feature would surely require JavaScript but 
IMHO it would be a really nice enhancement.

Also, search suggestions would require existence of some search 
service on the server. I believe that without too much effort an 
indexer can be written that will feed data to ElasticSearch[1] 
which would be used by a search service.


What do you think? (Just note that this is not final design, I'm 
not really happy with typography here, but it shows concept good)



[1] http://www.elasticsearch.org/
Apr 19 2014
next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 April 2014 11:56, Aleksandar Ruzicic via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but IMHO it would
 be a really nice enhancement.

 Also, search suggestions would require existence of some search service on
 the server. I believe that without too much effort an indexer can be written
 that will feed data to ElasticSearch[1] which would be used by a search
 service.


 What do you think? (Just note that this is not final design, I'm not really
 happy with typography here, but it shows concept good)



 [1] http://www.elasticsearch.org/



I'm more a fan of Solr myself.

https://lucene.apache.org/solr/
Apr 19 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 11:06:45 UTC, Iain Buclaw via 
Digitalmars-d wrote:

 On 19 April 2014 11:56, Aleksandar Ruzicic via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but 
 IMHO it would
 be a really nice enhancement.

 Also, search suggestions would require existence of some 
 search service on
 the server. I believe that without too much effort an indexer 
 can be written
 that will feed data to ElasticSearch[1] which would be used by 
 a search
 service.


 What do you think? (Just note that this is not final design, 
 I'm not really
 happy with typography here, but it shows concept good)



 [1] http://www.elasticsearch.org/



 I'm more a fan of Solr myself.

 https://lucene.apache.org/solr/


I have experience with ElasticSearch but I'm open to all 
suggestions, if Solr is better, then we'll use Solr.
But this is something Walter must approve first, as it would mean 
ditching Google search in favor of our own search service.
Apr 19 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-04-19 13:09, Aleksandar Ruzicic wrote:


 I have experience with ElasticSearch but I'm open to all suggestions, if
 Solr is better, then we'll use Solr.
 But this is something Walter must approve first, as it would mean
 ditching Google search in favor of our own search service.


They're quire similar. Both builds on Lucene.

-- 
/Jacob Carlborg
Apr 20 2014
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 19.04.2014 12:56, schrieb Aleksandar Ruzicic:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but IMHO it
 would be a really nice enhancement.

 Also, search suggestions would require existence of some search service
 on the server. I believe that without too much effort an indexer can be
 written that will feed data to ElasticSearch[1] which would be used by a
 search service.


 What do you think? (Just note that this is not final design, I'm not
 really happy with typography here, but it shows concept good)



 [1] http://www.elasticsearch.org/


Note that for the new library documentation layout a similar search 
feature is already implemented (although not yet online), so the data is 
available.
Apr 19 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 12:04:11 UTC, Sönke Ludwig wrote:

 Am 19.04.2014 12:56, schrieb Aleksandar Ruzicic:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but 
 IMHO it
 would be a really nice enhancement.

 Also, search suggestions would require existence of some 
 search service
 on the server. I believe that without too much effort an 
 indexer can be
 written that will feed data to ElasticSearch[1] which would be 
 used by a
 search service.


 What do you think? (Just note that this is not final design, 
 I'm not
 really happy with typography here, but it shows concept good)



 [1] http://www.elasticsearch.org/


 Note that for the new library documentation layout a similar 
 search feature is already implemented (although not yet 
 online), so the data is available.


That's excellent news! Would it be possible to use it to search 
through language reference too?
Apr 19 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but IMHO it
 would be a really nice enhancement.


I don't know anything about the specific search-suggestion engines, but 
as far as looks I (mostly) really like it. Only two comments:

- There should be some visual indication of the search box besides the 
text itself. It *looks* nice as you have it, but practically speaking 
it'd be a bit awkward to not be able to see the box itself.

- A *lot* of search boxes on the internet these days bake the "Enter 
search term here" (or whatever) text into the HTML, forcing non-JS users 
to delete the text before they're able to enter their search term. 
That's bad UX. Instead, the "Enter search term here" text should be 
*added* via JS and left blank in the raw HTML. That's a trivial way to 
ensure it works great for both JS and non-JS users.
Apr 19 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:

 On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but 
 IMHO it
 would be a really nice enhancement.


 I don't know anything about the specific search-suggestion 
 engines, but as far as looks I (mostly) really like it. Only 
 two comments:

 - There should be some visual indication of the search box 
 besides the text itself. It *looks* nice as you have it, but 
 practically speaking it'd be a bit awkward to not be able to 
 see the box itself.


OK, I'll work on a design more, I'll also try to have real 
designers involved to help me with these UX stuff.


 - A *lot* of search boxes on the internet these days bake the 
 "Enter search term here" (or whatever) text into the HTML, 
 forcing non-JS users to delete the text before they're able to 
 enter their search term. That's bad UX. Instead, the "Enter 
 search term here" text should be *added* via JS and left blank 
 in the raw HTML. That's a trivial way to ensure it works great 
 for both JS and non-JS users.


Nowdays there is something called placeholder attribute[1] on 
input elements that servers just for that purpose (text goes away 
as soon as you start typing) and there is no JS needed for that 
as it is supported by all major browsers. But I like to add 
fallback (that works even without JS, but better with JS) for 
that on old browsers which don't support that feature.


[1] 
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms_in_HTML#The_placeholder_attribute
Apr 19 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote:

 On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:

 - There should be some visual indication of the search box besides the
 text itself. It *looks* nice as you have it, but practically speaking
 it'd be a bit awkward to not be able to see the box itself.


 OK, I'll work on a design more, I'll also try to have real designers
 involved to help me with these UX stuff.


Honestly, I think you're selling yourself short here. You appear to have 
a pretty good eye for design.


 - A *lot* of search boxes on the internet these days bake the "Enter
 search term here" (or whatever) text into the HTML, forcing non-JS
 users to delete the text before they're able to enter their search
 term. That's bad UX. Instead, the "Enter search term here" text should
 be *added* via JS and left blank in the raw HTML. That's a trivial way
 to ensure it works great for both JS and non-JS users.


 Nowdays there is something called placeholder attribute[1] on input
 elements that servers just for that purpose (text goes away as soon as
 you start typing) and there is no JS needed for that as it is supported
 by all major browsers. But I like to add fallback (that works even
 without JS, but better with JS) for that on old browsers which don't
 support that feature.


 [1]
 https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms_in_HTML#The_placeholder_attribute


Interesting, first I've heard of it. I'll have to try it out, see if 
browsers are intelligent enough to *not* make users delete it when JS is 
off. If so, then that's a pretty nice attribute.
Apr 19 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 23:10:58 UTC, Nick Sabalausky wrote:

 On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote:

 On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky 
 wrote:

 - There should be some visual indication of the search box 
 besides the
 text itself. It *looks* nice as you have it, but practically 
 speaking
 it'd be a bit awkward to not be able to see the box itself.


 OK, I'll work on a design more, I'll also try to have real 
 designers
 involved to help me with these UX stuff.


 Honestly, I think you're selling yourself short here. You 
 appear to have a pretty good eye for design.


Heh, that's nice to hear, tnx! :) But I have never before 
designed a website so I'm pretty skeptical about it.

It seems that years of slicing and coding website designs thought 
me something, so it's not entirely waster years there.. :)


 [snip]
 Interesting, first I've heard of it. I'll have to try it out, 
 see if browsers are intelligent enough to *not* make users 
 delete it when JS is off. If so, then that's a pretty nice 
 attribute.


Yep, it' really nice UX element and it works without JS too! :)
Apr 19 2014
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
 But I like to add fallback (that works even without JS, but 
 better with JS) for that on old browsers which don't support 
 that feature.


You could make a poll on the newsgroup or ask Andrei if Google 
Analytics has some numbers about the User Agents used to visit 
our site. My guess is that we can safely ignore IE8 for our 
target group.
Apr 23 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Wednesday, 23 April 2014 at 07:16:53 UTC, Martin Nowak wrote:

 But I like to add fallback (that works even without JS, but 
 better with JS) for that on old browsers which don't support 
 that feature.


 You could make a poll on the newsgroup or ask Andrei if Google 
 Analytics has some numbers about the User Agents used to visit 
 our site. My guess is that we can safely ignore IE8 for our 
 target group.


I would support IE8 too, as that is the latest IE you can get on 
XP. I know that Microsoft has discontinued XP but there are still 
fare share of XP users out there..

But I will leave all that cross-browser tweaking for last stage..
Apr 23 2014
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 19 April 2014 at 10:56:07 UTC, Aleksandar Ruzicic 
wrote:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but 
 IMHO it would be a really nice enhancement.


Yes it would. It could be done as an independent second step 
though.


 What do you think? (Just note that this is not final design, 
 I'm not really happy with typography here, but it shows concept 
 good)


We can easily find better fonts :).
Apr 23 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Wednesday, 23 April 2014 at 07:28:51 UTC, Martin Nowak wrote:

 On Saturday, 19 April 2014 at 10:56:07 UTC, Aleksandar Ruzicic 
 wrote:

 Ok here's a mockup of search concept I would like to implement:

 http://krcko.net/dlang.org/dlang-search-concept.png

 Search suggestions feature would surely require JavaScript but 
 IMHO it would be a really nice enhancement.


 Yes it would. It could be done as an independent second step 
 though.


Yep, that's how I plan to do it. First just to redesign the 
complete website then to add features like search suggestions.


 What do you think? (Just note that this is not final design, 
 I'm not really happy with typography here, but it shows 
 concept good)


 We can easily find better fonts :).


I'm not that unsatisfied with font faces (its Consolas nad 
Calibri), more with sizes/spacing/colors.. But this is something 
I will go over with a great graphics designer who will join me at 
the start of May, so it will surely be much better.
Apr 23 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
wrote:

 I must respectfully disagree about retaining left justification.
 I have 27'' monitor with resolution of 2560x1440 and 
 left-aligned websites are really hard to read!

 There is a reason why most editors have "zen mode" which 
 centers your code on a screen. It's easier to read when it's 
 centered and not too wide.


You can have the browser window centered on screen and have your 
preferred width. It doesn't make sense to have wide window if 
don't ever want anything that wide, then every site which fits 
the window width automatically has your preferred width, 
otherwise the designer would need to figure out everyone's 
preferred width and accommodate for that, but how?


 [1] http://devdocs.io/


"Sorry, your browser is not supported". I would understand, if it 
was an FPS web game, but what advanced technology a documentation 
site absolutely can't live without?
Apr 19 2014
next sibling parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 11:48:39 UTC, Kagamin wrote:

 On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
 wrote:

 I must respectfully disagree about retaining left 
 justification.
 I have 27'' monitor with resolution of 2560x1440 and 
 left-aligned websites are really hard to read!

 There is a reason why most editors have "zen mode" which 
 centers your code on a screen. It's easier to read when it's 
 centered and not too wide.


 You can have the browser window centered on screen and have 
 your preferred width. It doesn't make sense to have wide window 
 if don't ever want anything that wide, then every site which 
 fits the window width automatically has your preferred width, 
 otherwise the designer would need to figure out everyone's 
 preferred width and accommodate for that, but how?


I like my browser window maximized, that's how I've been using it 
for more than 10 years. And I'm not the only one. For other 
windows (editor/chat/etc) I have two additional monitors.
It si true that it's impossible to satisfy all tastes but in my 
experience majority of websites nowadays are centered.

But, when I say centered I mean having a maximum width of say 
1200px, so that on most common resolutions it will be full-page 
website or it will be just slightly padded on both sides. Content 
would be left aligned, of course.

On resolutions larger than 1200px in width additions information 
could be provided (from both sides, so that content stays 
centered and thus in spotlight).



 [1] http://devdocs.io/


 "Sorry, your browser is not supported". I would understand, if 
 it was an FPS web game, but what advanced technology a 
 documentation site absolutely can't live without?


Which browser do you use? I've used it only on Firefox (Aurora to 
be precise) and it works flawlessly.
That was just an example of how convenient is to have 
documentation filtered as you type. I'm not planning to make 
"devdoc for d", just to provide nearly instantaneously results as 
user types search query.
Apr 19 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 7:48 AM, Kagamin wrote:

 On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote:


 [1] http://devdocs.io/


 "Sorry, your browser is not supported". I would understand, if it was an
 FPS web game, but what advanced technology a documentation site
 absolutely can't live without?


I get "This site is asking to store data on your computer for offline use".

I always decline that sort of thing. Aside from games (which really 
belong outside the browser anyway), anything that can't be handled via a 
normal session cookie is questionable and doesn't belong on my computer.
Apr 19 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 21:49:20 UTC, Nick Sabalausky wrote:

 On 4/19/2014 7:48 AM, Kagamin wrote:

 On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
 wrote:


 [1] http://devdocs.io/


 "Sorry, your browser is not supported". I would understand, if 
 it was an
 FPS web game, but what advanced technology a documentation site
 absolutely can't live without?


 I get "This site is asking to store data on your computer for 
 offline use".

 I always decline that sort of thing. Aside from games (which 
 really belong outside the browser anyway), anything that can't 
 be handled via a normal session cookie is questionable and 
 doesn't belong on my computer.


They use it to remember your selection of languages/frameworks if 
I'm not mistaken.

That can surely be stored in a Cookie, but I also prefer 
localStorage, mostly for performance reasons (cookies get sent on 
*every* request, unless you setup subdomain just for that type of 
cookies) and for the fact that cookies are the worst thing ever 
happened to HTTP :)
Apr 19 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote:

 That can surely be stored in a Cookie, but I also prefer localStorage,
 mostly for performance reasons (cookies get sent on *every* request,
 unless you setup subdomain just for that type of cookies) and for the
 fact that cookies are the worst thing ever happened to HTTP :)


Session cookies are a few **bytes** in size. Selection of 
languages/frameworks would also be a mere handful of bytes. That's 
completely dwarfed by just the HTTP headers alone.

There is *NO* performance issue here whatsoever unless you're on a 
circa-1980's dial-up (in which case the cookie itself *still* isn't 
going to be the main performance issue ;) )
Apr 19 2014
parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 23:06:55 UTC, Nick Sabalausky wrote:

 On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote:

 That can surely be stored in a Cookie, but I also prefer 
 localStorage,
 mostly for performance reasons (cookies get sent on *every* 
 request,
 unless you setup subdomain just for that type of cookies) and 
 for the
 fact that cookies are the worst thing ever happened to HTTP :)


 Session cookies are a few **bytes** in size. Selection of 
 languages/frameworks would also be a mere handful of bytes. 
 That's completely dwarfed by just the HTTP headers alone.

 There is *NO* performance issue here whatsoever unless you're 
 on a circa-1980's dial-up (in which case the cookie itself 
 *still* isn't going to be the main performance issue ;) )


Yes they are few bytes but they are sent for *every* request. 
That includes every image, every css/js file..

When working on large scale you want to avoid any unnecessary 
headers, not so much because of a client but because of a server.

I work on a website that has millions unique visits weakly and 
when I've introduced new subdomain for static content (so that 
cookies wouldn't be sent for every image, and images are major 
form of content there) we've noticed improvements on server's 
performance charts.

So I'll always argue that having less cookies means (even 
slightly) better performance :)

But anyway, we're going slightly off-topic with this..
Apr 19 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 7:19 PM, Aleksandar Ruzicic wrote:

 On Saturday, 19 April 2014 at 23:06:55 UTC, Nick Sabalausky wrote:

 On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote:

 That can surely be stored in a Cookie, but I also prefer localStorage,
 mostly for performance reasons (cookies get sent on *every* request,
 unless you setup subdomain just for that type of cookies) and for the
 fact that cookies are the worst thing ever happened to HTTP :)


 Session cookies are a few **bytes** in size. Selection of
 languages/frameworks would also be a mere handful of bytes. That's
 completely dwarfed by just the HTTP headers alone.

 There is *NO* performance issue here whatsoever unless you're on a
 circa-1980's dial-up (in which case the cookie itself *still* isn't
 going to be the main performance issue ;) )


 Yes they are few bytes but they are sent for *every* request. That
 includes every image, every css/js file..

 When working on large scale you want to avoid any unnecessary headers,
 not so much because of a client but because of a server.


Doesn't matter if you're talking server or client, it's still the same 
miniscule proportion of the total. Even for the server to receive it for 
every css/js file request, even if they *aren't* cached (and 
realistically they will be), it's still a mere drop in the bucket.

Suppose if it were as much as 100 bytes, which would be fairly large for 
a cookie (mine total around 50 bytes or less when sent to the server), 
then even 1000 requests (considerably larger than a typical session, 
unless it's being overly-AJAXy, which would be a bigger performance 
drain for both server/client than cookies anyway) is *still* just 100kB 
which, for a modern server and that many requests, is nothing. It's 
still *completely* dwarfed by all the other crap in the client's headers 
alone, let alone the actual payload data being transferred back which, 
in most cases, will be considerably larger still.
Apr 19 2014
prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote:

 I must respectfully disagree about retaining left justification.
 I have 27'' monitor with resolution of 2560x1440 and left-aligned
 websites are really hard to read!


Why does everyone these days seem to forget that windows are resizable?

FWIW though, I find *everything* freaking unreadable and barely-usable 
on a 16:9 - good for media, worthless for computing.


 There is a reason why most editors have "zen mode" which centers your
 code on a screen. It's easier to read when it's centered and not too 


wide.

 Current design has no limitation on line width which (at my resolution)
 results in ~300 characters wide lines, and it's really unreadable.

 I would go for a maximum of 120 characters wide lines with content
 centered on larger monitors.



Text justification has nothing to do with maximum line width. 
"max-width" works perfectly fine with left-justified, too.

And left-justified makes it easier to distinguish individual lines, 
otherwise it's easier to loose your place when reading from one line 
down to the next line. Plus it does suffer from those 
inconsistently-sized spaces.
Apr 19 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 21:34:31 UTC, Nick Sabalausky wrote:

 On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote:

 I must respectfully disagree about retaining left


 justification.

 I have 27'' monitor with resolution of 2560x1440 and


 left-aligned

 websites are really hard to read!


 Why does everyone these days seem to forget that windows are 
 resizable?

 FWIW though, I find *everything* freaking unreadable and 
 barely-usable on a 16:9 - good for media, worthless for 
 computing.


 There is a reason why most editors have "zen mode" which


 centers your

 code on a screen. It's easier to read when it's centered and


 not too wide.

 Current design has no limitation on line width which (at my


 resolution)

 results in ~300 characters wide lines, and it's really


 unreadable.

 I would go for a maximum of 120 characters wide lines with


 content

 centered on larger monitors.



 Text justification has nothing to do with maximum line width. 
 "max-width" works perfectly fine with left-justified, too.

 And left-justified makes it easier to distinguish individual 
 lines, otherwise it's easier to loose your place when reading 
 from one line down to the next line. Plus it does suffer from 
 those inconsistently-sized spaces.


As I've said in one of previous messages, text will be 
left-aligned, there is no way I would make it centered. I was 
talking about layout alignment.

I was talking about max-width as a means to keep text readable, 
as 300 characters per line is really too hard to read.

It seems I'll have to implement this design proposal in HTML/CSS 
to be able to better communicate design decisions.
Apr 19 2014
prev sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
wrote:

 I have 27'' monitor with resolution of 2560x1440 and


Yeah, me too...


 left-aligned websites are really hard to read!


...so I have no idea what you're even talking about with this 
statement.


 There is a reason why most editors have "zen mode" which 
 centers your code on a screen. It's easier to read when it's 
 centered and not too wide.


"most"? I have literally never seen this on any editor ever.  But 
that's beside the point.


 Current design has no limitation on line width which (at my 
 resolution) results in ~300 characters wide lines, and it's 
 really unreadable.


To be clear, I'm not favouring unreadable CPL.  I'm specifically 
against the useless gutters to the left and right that, alone, 
are each too narrow to be particularly useful.  Never mind that 
they account for roughly half of my screen area.  I'm not 
inclined to support any design with that much wasted space.

Oddly enough, Wikipedia's main page gets this right: 
http://en.wikipedia.org/wiki/Main_Page (Though I admit it doesn't 
degrade gracefully to more narrow dimensions).

If proper aspect ratios hadn't been killed by cheapskate panel 
manufacturers, we probably wouldn't even be having this 
discussion.

-Wyatt
Apr 21 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 09:40:53 UTC, Wyatt wrote:

 On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic 
 wrote:

 I have 27'' monitor with resolution of 2560x1440 and


 Yeah, me too...


 left-aligned websites are really hard to read!


 ...so I have no idea what you're even talking about with this 
 statement.


I have by browser's window maximized and websites with lot of 
text that are left-aligned are (to me at least) hard to read as I 
need to move focus from center of the monitor to the left edge, 
and staring at the angle like that for some time makes my eyes 
hurt..



 There is a reason why most editors have "zen mode" which 
 centers your code on a screen. It's easier to read when it's 
 centered and not too wide.


 "most"? I have literally never seen this on any editor ever.  
 But that's beside the point.


Sublime Text has this, it's called distraction free mode, there 
was extension for Komodo IDE too, but I haven't used it for years.



 Current design has no limitation on line width which (at my 
 resolution) results in ~300 characters wide lines, and it's 
 really unreadable.


 To be clear, I'm not favouring unreadable CPL.  I'm 
 specifically against the useless gutters to the left and right 
 that, alone, are each too narrow to be particularly useful.  
 Never mind that they account for roughly half of my screen 
 area.  I'm not inclined to support any design with that much 
 wasted space.


I'll try to use as much space as possible. I've said in one of 
previous messages that extra screen space can (and will) be used 
for displaying additional content.


 Oddly enough, Wikipedia's main page gets this right: 
 http://en.wikipedia.org/wiki/Main_Page (Though I admit it 
 doesn't degrade gracefully to more narrow dimensions).


Yeah, Wikipedia looks good on wide monitors but as you said it's 
multi-column layout doesn't scale well.


 If proper aspect ratios hadn't been killed by cheapskate panel 
 manufacturers, we probably wouldn't even be having this 
 discussion.

 -Wyatt


Agreed. :)
Apr 21 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 <snip>

 I have also tried to design something myself (although I'm not 
 a designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?


Even if it weren't better looking, just different, I'd say it 
should be done. I'm of the opinion that every site, no matter how 
good it looks, should go through redesigns periodically in order 
to feel fresh and non-stagnant to repeat visitors. It's a form of 
marketing that reassures users that something is being actively 
developed.

That said, I also happen to think your design looks fantastic and 
should replace the current one just based on its appearance and 
big improvements to usability. It feels more professional. I'm 
all for this change.
Apr 18 2014
next sibling parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:53:38 UTC, Brad Anderson wrote:

 Even if it weren't better looking, just different, I'd say it 
 should be done. I'm of the opinion that every site, no matter 
 how good it looks, should go through redesigns periodically in 
 order to feel fresh and non-stagnant to repeat visitors. It's a 
 form of marketing that reassures users that something is being 
 actively developed.


I completely agree with this. There is a website I work on from 
2007 which is completely redesigned every 1.5-2 years. There was 
just once major feature addition, all other redesigns are done 
for marketing reasons.
Apr 18 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 12:53 PM, Brad Anderson wrote:

 Even if it weren't better looking, just different, I'd say it should be
 done. I'm of the opinion that every site, no matter how good it looks,
 should go through redesigns periodically in order to feel fresh and
 non-stagnant to repeat visitors. It's a form of marketing that reassures
 users that something is being actively developed.


On a philosophical level, I *very* strongly disagree with this as I 
think it amounts to deliberate enforcement of "screwing with shit that 
ain't broke just for the sake of fucking around with it". If anything, 
I'm more likely lose respect for things that can't just decide on a 
look/layout and stick with it.

Constantly keeping *CONTENT* up-to-date is *far* more indicative of 
active development than constant rejiggering of trivialities like style. 
The latter gives the impression that the developers have their 
priorities all wrong and are actively looking for anything to distract 
themselves with.

*BUT*, I admit that's all just academic since I *do* agree that the 
proposed new design does indeed look fantastic and is worthy of 
replacing the current one.


 That said, I also happen to think your design looks fantastic and should
 replace the current one just based on its appearance and big
 improvements to usability. It feels more professional. I'm all for this
 change.
Apr 19 2014
parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4/20/14, Nick Sabalausky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On a philosophical level, I *very* strongly disagree with this as I
 think it amounts to deliberate enforcement of "screwing with shit that
 ain't broke just for the sake of fucking around with it".


Yep. Also see how often MSDN breaks their links to their docs. Not
that they were ever descriptive, which is another bad UX example. E.g.
a page named "dd183370(v=vs.85).aspx".
Apr 19 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 But, all this time D's official website somehow archaic look 
 kept troubling me. It reminds me of early 2000's design and I 
 really cannot associate this design with "modern" or "elegant", 
 what D really is.


Agreed.



 So, what do you guys think?


Very nice! Huge improvement!
Apr 18 2014
prev sibling next sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 http://krcko.net/dlang.org/dlang-home-draft1.png


Isn't it only Microsoft PR department, who call metro style 
modern? I'm surprised there're people who took it by heart.
Apr 18 2014
parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 18:53:47 UTC, Kagamin wrote:

 On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
 wrote:

 http://krcko.net/dlang.org/dlang-home-draft1.png


 Isn't it only Microsoft PR department, who call metro style 
 modern? I'm surprised there're people who took it by heart.


This is not really a "metro design", but I admit it sure looks a 
bit like it.
I find these flat designs great, they help to make content stand 
out more.

And it is not only Microsoft who are pushing flat as modern way 
of doing design (but as far as I know they are one of firsts)..
Apr 18 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?


Nice initiative, but the top bar looks a lot like adobe.com . I 
think something less corporate would be more suitable. What are 
you trying to communicate? A community or a corporation?

What kind of signals are you sending to the first time visitor? 
Is he a customer, consumer, participant, etc…
Apr 18 2014
next sibling parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 18:56:38 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
 wrote:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?


 Nice initiative, but the top bar looks a lot like adobe.com . I 
 think something less corporate would be more suitable. What are 
 you trying to communicate? A community or a corporation?

 What kind of signals are you sending to the first time visitor? 
 Is he a customer, consumer, participant, etc…


I was aiming for something that will communicate "this is a 
website of powerful, modern programming language". I wanted 
something that looks "professional", which is something that can 
be associated with both serious community and a corporation.

Anyway, I have already said in one of previous posts that this is 
just a mockup and that I will try to have real designer involved 
(I'm not designer). I made this just to show direction in which I 
think we should go with dlang.org.
Apr 18 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 18 April 2014 at 20:04:53 UTC, Aleksandar Ruzicic 
wrote:

 I wanted something that looks "professional", which is 
 something that can be associated with both serious community 
 and a corporation.


In the past decade there has been so many startups with 
programming frameworks that go bust and leave the developers with 
nothing so I think it is important that the site communicate 
"community". They tend to stick around longer.

It is usually a good idea to take a look at the competing sites. 
This is because:

1. visitors are likely to be familiar with one of those
2. they might have figured out something that works
3. you want to do at least what they do, but better

http://www.rust-lang.org/
http://golang.org/
https://www.python.org/
https://www.dartlang.org/

etc.
Apr 18 2014
next sibling parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 20:12:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 18 April 2014 at 20:04:53 UTC, Aleksandar Ruzicic 
 wrote:

 I wanted something that looks "professional", which is 
 something that can be associated with both serious community 
 and a corporation.


 In the past decade there has been so many startups with 
 programming frameworks that go bust and leave the developers 
 with nothing so I think it is important that the site 
 communicate "community". They tend to stick around longer.

 It is usually a good idea to take a look at the competing 
 sites. This is because:

 1. visitors are likely to be familiar with one of those
 2. they might have figured out something that works
 3. you want to do at least what they do, but better

 http://www.rust-lang.org/
 http://golang.org/
 https://www.python.org/
 https://www.dartlang.org/

 etc.


I really like rust-lang.org, I was thinking of using it as a base 
for design but decided against it because I don't want dlang.org 
to be accused of ripping of rust-lang.org.

golang.org is not really readable in my opinion. There is not 
enough distinction between page components (there is no area on 
that design that catches your eye as soon as you look at page).

python.org is one of my favorite websites, they really did good 
job.

dartlang.org is nice, cleanly designed website. It reminds me of 
a website of programming framework produced by some startup :)

I also like ruby-lang.org and recently-redesigned php.net
Apr 18 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
 I really like rust-lang.org, I was thinking of using it as a 
 base for design but decided against it because I don't want 
 dlang.org to be accused of ripping of rust-lang.org.


:-) I like rust-lang for being concise and outspoken about what 
they are all about, but not very verbose on the front page. It 
makes me curious and I want to visit another page for more 
information.

Maybe there is a little bit too much text on the front page of 
the current D-site.

rust-lang push the longer text to the second page, but is very 
focused on what makes rust stand out. Maybe that is a good idea, 
because when you click for one more page you maybe feel a bit 
more committed and are more likely to read it?


 dartlang.org is nice, cleanly designed website. It reminds me 
 of a website of programming framework produced by some startup 
 :)


Yeah, I agree, it is a bit bland. But both go and dart are google 
projects, and they try to "frame" the sites as community-oriented 
and avoid the "corporate taint"?

I also like the go-lang way of having a "live" tutorial as their 
front page.

Ola.
Apr 18 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic 
wrote:

 I really like rust-lang.org, I was thinking of using it as a 
 base for design but decided against it because I don't want 
 dlang.org to be accused of ripping of rust-lang.org.


This navigation layout was used for centuries in paper books. 
Recently it was used by gcc docs and w3c docs. I personally see 
no reason for the side bar: it's never used, just wastes space, 
which could be used even on 2500 display and maximized browser 
window: font can be zoomed too, then the side bar becomes a 
nuisance, while remaining useless (the case for forum.dlang.org).


 python.org is one of my favorite websites, they really did good 
 job.


Doesn't it use gradients and 3D effects to emphasize structural 
elements? You use some borders too, which qualify as non-content 
color effects, can be seen as 3D to some extent. True metro style 
is ultimate flatness and indiscernible structure, I work with 
such applications at work, hence my rage every time I hear about 
modern UI.
Apr 21 2014
next sibling parent "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 12:01:09 UTC, Kagamin wrote:

 On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic 
 wrote:

 I really like rust-lang.org, I was thinking of using it as a 
 base for design but decided against it because I don't want 
 dlang.org to be accused of ripping of rust-lang.org.


 This navigation layout was used for centuries in paper books. 
 Recently it was used by gcc docs and w3c docs. I personally see 
 no reason for the side bar: it's never used, just wastes space, 
 which could be used even on 2500 display and maximized browser 
 window: font can be zoomed too, then the side bar becomes a 
 nuisance, while remaining useless (the case for 
 forum.dlang.org).


Sidebar can be hidden by use of  media queries as the window 
width becomes smaller (this is something I plan to do with new 
design).



 python.org is one of my favorite websites, they really did 
 good job.


 Doesn't it use gradients and 3D effects to emphasize structural 
 elements? You use some borders too, which qualify as 
 non-content color effects, can be seen as 3D to some extent. 
 True metro style is ultimate flatness and indiscernible 
 structure, I work with such applications at work, hence my rage 
 every time I hear about modern UI.


I've said few times that this is not metro style (I work with 
metro apps daily) it's just flat (no semi-3D effect like shadows 
and gradients).
Apr 21 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/21/14, 5:01 AM, Kagamin wrote:

 On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic wrote:

 I really like rust-lang.org, I was thinking of using it as a base for
 design but decided against it because I don't want dlang.org to be
 accused of ripping of rust-lang.org.


 This navigation layout was used for centuries in paper books. Recently
 it was used by gcc docs and w3c docs. I personally see no reason for the
 side bar: it's never used, just wastes space, which could be used even
 on 2500 display and maximized browser window: font can be zoomed too,
 then the side bar becomes a nuisance, while remaining useless (the case
 for forum.dlang.org).


Wait, are you advocating for text occupying the entire page width, like 
a telex band? Aren't text lines difficult to follow from the right side 
to the continuing left side? -- Andrei
Apr 21 2014
next sibling parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu 
wrote:

 On 4/21/14, 5:01 AM, Kagamin wrote:

 On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic 
 wrote:

 I really like rust-lang.org, I was thinking of using it as a 
 base for
 design but decided against it because I don't want dlang.org 
 to be
 accused of ripping of rust-lang.org.


 This navigation layout was used for centuries in paper books. 
 Recently
 it was used by gcc docs and w3c docs. I personally see no 
 reason for the
 side bar: it's never used, just wastes space, which could be 
 used even
 on 2500 display and maximized browser window: font can be 
 zoomed too,
 then the side bar becomes a nuisance, while remaining useless 
 (the case
 for forum.dlang.org).


 Wait, are you advocating for text occupying the entire page 
 width, like a telex band? Aren't text lines difficult to follow 
 from the right side to the continuing left side? -- Andrei


Yes, there were numerous studies about line length (I don't have 
any links to back this with but I'm sure that searching for "web 
typography line length" on google would provide some useful 
articles). And optimal line length is some 80-90 characters 
(including the whitespace), I'll try not to cross that boundary 
much.
Apr 21 2014
parent reply "Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 21 April 2014 at 15:15:22 UTC, Aleksandar Ruzicic 
wrote:

 Yes, there were numerous studies about line length (I don't 
 have any links to back this with but I'm sure that searching 
 for "web typography line length" on google would provide some 
 useful articles). And optimal line length is some 80-90 
 characters (including the whitespace), I'll try not to cross 
 that boundary much.


This isn't specific to the web.  The typographic rules about line 
lengths are probably as old as the printing press itself.

It annoys me that tried-and-true typographic best practices are 
constantly and blatantly ignored by web designers.

Relevant:
http://baymard.com/blog/line-length-readability
http://webtypography.net/toc/
Apr 22 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 22 April 2014 at 11:36:37 UTC, Lars T. Kyllingstad 
wrote:

 It annoys me that tried-and-true typographic best practices are 
 constantly and blatantly ignored by web designers.


Yeah, well, but the truth is that there is no solid truths 
because there are many variables: line height, font, display 
acuity, distance to display, reading patterns, age, words etc.

I remember when I was teaching at web design course and was 
trying to find solid research (it was for m.sc. students) for 
design guidelines for screens in general and finding something 
solid was very difficult.

For instance, people don't read web pages inititally. They scan 
them. So making the page easily scannable for interesting phrases 
might be more important than actual reading speed.

For users who are skilled at speed reading you want narrow 
columns so you have vertical movement (as in scientific papers 
and newspapers). For older people you want large fonts and high 
contrast. For high acuity displays you want serifs. It is a big 
problem that too many web-designers are young and don't take 
older and handicapped people into consideration.

Btw, I think the single word per frame app Spritz pretty much 
describes how difficult it is to put down absolute guidlines. I 
have no problem to follow it at 700wps:

http://www.spritzinc.com/
Apr 22 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu 
wrote:

 Wait, are you advocating for text occupying the entire page 
 width, like a telex band? Aren't text lines difficult to follow 
 from the right side to the continuing left side? -- Andrei


What's problem with entire page width? I don't remember 
difficulty reading w3c docs or gcc docs or linux man pages even 
when they occupy the entire page width.
Apr 22 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/22/14, 3:32 AM, Kagamin wrote:

 On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu wrote:

 Wait, are you advocating for text occupying the entire page width,
 like a telex band? Aren't text lines difficult to follow from the
 right side to the continuing left side? -- Andrei


 What's problem with entire page width? I don't remember difficulty
 reading w3c docs or gcc docs or linux man pages even when they occupy
 the entire page width.


https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off

Andrei
Apr 22 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu 
wrote:

 On 4/22/14, 3:32 AM, Kagamin wrote:

 What's problem with entire page width? I don't remember 
 difficulty
 reading w3c docs or gcc docs or linux man pages even when they 
 occupy
 the entire page width.


 https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off


As I have already pointed out, there is no optimal width. E.g. if 
you have 3 lines per paragraph you can have longer lines. If you 
have 20 lines per paragrap you need shorter ones. So why are you 
doing this? Trying to be clever? Obviously not.

Kagamin meant "window width". Clearly if the user can adjust his 
window he can get the desired text width. Only after two decades 
of academics pointing out a need for flexible width do web 
designers get it and start chanting for "responsive design". Not 
because they actually understand what they are doing, but because 
they were FORCED to leave their ugly fixed width obsession by the 
introduction of mobile devices.

Too many documentation sites still get this wrong, meaning: they 
don't work properly if the user sets a larger font or uses his 
own stylesheets.

This is the proper link:

http://www.w3.org/TR/WCAG20-TECHS/

(You ARE flame baiting, right? I think you owe Kagamin an 
apology.)
Apr 22 2014
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/22/2014 4:39 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 This is the proper link:

 http://www.w3.org/TR/WCAG20-TECHS/


Man do I REALLY wish movie makers and game devs would at least TRY to 
follow this one:

http://www.w3.org/TR/WCAG20-TECHS/G56.html

In just the last decade, it's become absurdly common for dialog to be 
*quieter* than sound effects and background music. Insane.
Apr 22 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/22/14, 1:39 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:

 On 4/22/14, 3:32 AM, Kagamin wrote:

 What's problem with entire page width? I don't remember difficulty
 reading w3c docs or gcc docs or linux man pages even when they occupy
 the entire page width.


 https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off


 As I have already pointed out, there is no optimal width. E.g. if you
 have 3 lines per paragraph you can have longer lines. If you have 20
 lines per paragrap you need shorter ones.


According to the top hits in the search I posted, your point is not valid.


 So why are you doing this?
 Trying to be clever? Obviously not.


I don't understand the motivation of this quip.


 Kagamin meant "window width". Clearly if the user can adjust his window
 he can get the desired text width.


Today's crop of browsers are tabbed, and for many users the position of 
the browser window is dictated by external constraints (relation to 
other windows, external monitor or not etc) and it's unreasonable to 
demand resizing the window whenever they swap tabs.


 Only after two decades of academics
 pointing out a need for flexible width do web designers get it and start
 chanting for "responsive design". Not because they actually understand
 what they are doing, but because they were FORCED to leave their ugly
 fixed width obsession by the introduction of mobile devices.


Strawman. I'm not advocating for fixed width.


 Too many documentation sites still get this wrong, meaning: they don't
 work properly if the user sets a larger font or uses his own stylesheets.

 This is the proper link:

 http://www.w3.org/TR/WCAG20-TECHS/

 (You ARE flame baiting, right? I think you owe Kagamin an apology.)


Wut? This is weird, but whatevs. Just please don't charge him attorney 
fees :o).


Andrei
Apr 22 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu 
wrote:

 Trying to be clever? Obviously not.


 I don't understand the motivation of this quip.


You don't understand that it is offensive to respond to an 
intelligent question by posting a Google query? As a project 
maintainer you should know better.

If dlang.org is being used by a programmer for 2-3 hours daily, 
then it is his use scenario that matters. The ability to adapt is 
more important for a documentation site than for a news site.

There are many good reasons to scale up to insane widths, 
basically to cut down the length of the rendered page to get an 
overview. To get less prose and more code on the page. Many of 
the dlang pages suffers from being too long, information sought 
is "hidden".

The user is always right… as the a designer you cannot tell the 
user he is wrong (well, you can, but that will only piss him 
off). So if Kagamin is comfortable with wide windows then that 
most certainly is the right thing for him.

Anyway, you guys are taking this process in reverse. You should 
start with use cases, then the requirements, then content, then 
functionality, then marginal design, then figure out what you 
need in addition in terms of styling.

The current documentation is not very user friendly, no amount of 
styling will fix that. Styling will only make it look like you 
have your priorities wrong. Put a dress on a pig and it will 
still be a pig, an odd one. (In the commercial sector you start 
with stylish mockups, but that is only a political move to get 
thumbs up, it is not a good idea since it can lock down 
expectations too early.)

A redesign ought to:

1. cut down on the number of operations to find the information 
sought.

2. maximize vertical information flow to avoid exessive scrolling 
(that means get rid of the top bar on doc pages)

I think you need to improve ddoc and get more semantics into the 
markup.


 Today's crop of browsers are tabbed, and for many users the 
 position of the browser window is dictated by external 
 constraints (relation to other windows, external monitor or not 
 etc) and it's unreasonable to demand resizing the window 
 whenever they swap tabs.


I would image the primary usage scenario is to have dlang 
alongside your editor. (Doing a mobile-first design for dlang is 
something I don't get the point of.)

Ola.
Apr 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 3:13 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu wrote:

 Trying to be clever? Obviously not.


 I don't understand the motivation of this quip.


 You don't understand that it is offensive to respond to an intelligent
 question by posting a Google query? As a project maintainer you should
 know better.


As a project maintainer I try to foster good exchange of information. I 
found the link informative. -- Andrei
Apr 23 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 16:13:42 UTC, Andrei Alexandrescu 
wrote:

 On 4/23/14, 3:13 AM, "Ola Fosheim Grøstad"


 You don't understand that it is offensive to respond to an 
 intelligent
 question by posting a Google query? As a project maintainer 
 you should
 know better.


 As a project maintainer I try to foster good exchange of 
 information. I found the link informative. -- Andrei


In most contexts that will be taken as a RTFM response, as in: 
«why didn't you search for this yourself?»
Apr 23 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu 
wrote:

 https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off


The first link say 100 characters per line. If 100 characters 
equal to page width, then page width is the optimal line length.
Apr 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 4:30 AM, Kagamin wrote:

 On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:

 https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off


 The first link say 100 characters per line. If 100 characters equal to
 page width, then page width is the optimal line length.


Maybe Google personalized my search, but the first hit is 
http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-readin
-digital-vs-printed 
pointing to a study indicating 95 characters per line as optimal for 
on-screen reading comprehension. The subjective preferences, however, 
was biased toward smaller numbers.

The second link is http://baymard.com/blog/line-length-readability which 
points to a few studies concluding that 50-75 cpl (characters per line) 
would be indicated for web design.

Third is 
http://stackoverflow.com/questions/7460041/whats-a-good-maximum-width-
f-text-on-a-webpage 
which quotes a really nice collection of numbers from Smashing Magazine 
from popular websites, showing that 84% of the sites they looked at use 
65-104 cpl.

It just struck me that Google's own search page that I'm looking at 
right now, which I vaguely recall did not limit line lengths a few years 
ago, is now using a 90 cpl limit. The page's right-hand side is a white 
area.

Next is 
http://webstyleguide.com/wsg3/7-page-design/6-page-width-line-length.html, 
which mentions 66 cpl as optimal from a physiological standpoint.

Next is http://socialtriggers.com/perfect-content-width/ which nicely 
advocates smaller cpl at the top of the content (so people read the 
essential message quickly) followed by 100 cpl.

And so on and so forth.

====

So I'd dlang.org to foster a behavior depending on the available real 
estate, as follows:

* Cap cpl at e.g. 110 on very large screens.

* As the available width decreases, reduce cpl up to 60.

* If cpl with sidebar falls below 60, remove the sidebar and obtain e.g. 
80 cpl.

* As the available width reduces further, allow reduction down to e.g. 
35 cpl, and then require horizontal scrolling.


Andrei
Apr 23 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu 
wrote:

 ... first hit is 
 http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-readin
-digital-vs-printed 
 pointing to a study indicating 95 characters per line as 
 optimal for on-screen reading comprehension. The subjective 
 preferences, however, was biased toward smaller numbers.

 The second link is 
 http://baymard.com/blog/line-length-readability which points to 
 a few studies concluding that 50-75 cpl (characters per line) 
 would be indicated for web design.

 Third is 
 http://stackoverflow.com/questions/7460041/whats-a-good-maximum-width-
f-text-on-a-webpage 
 which quotes a really nice collection of numbers from Smashing 
 Magazine from popular websites, showing that 84% of the sites 
 they looked at use 65-104 cpl.

 It just struck me that Google's own search page that I'm 
 looking at right now, which I vaguely recall did not limit line 
 lengths a few years ago, is now using a 90 cpl limit. The 
 page's right-hand side is a white area.

 Next is 
 http://webstyleguide.com/wsg3/7-page-design/6-page-width-line-length.html, 
 which mentions 66 cpl as optimal from a physiological 
 standpoint.

 Next is http://socialtriggers.com/perfect-content-width/ which 
 nicely advocates smaller cpl at the top of the content (so 
 people read the essential message quickly) followed by 100 cpl.


Gosh now I finally know what researches to blame for my eyes 
bleeding upon most web site restylings (Facebook *caugh-caugh*). 
If anything it just shows that overall reading skills are 
decreasing and no one care about visitors with small fonts (me). 
But current HTML/CSS standards don't provide way to express sizes 
as percentage of screen width (as opposed to page window width), 
do they?
Apr 23 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 9:28 AM, Dicebot wrote:

 Gosh now I finally know what researches to blame for my eyes bleeding
 upon most web site restylings (Facebook *caugh-caugh*). If anything it
 just shows that overall reading skills are decreasing and no one care
 about visitors with small fonts (me). But current HTML/CSS standards
 don't provide way to express sizes as percentage of screen width (as
 opposed to page window width), do they?


I don't know. It's a good question and an interesting challenge. -- Andrei
Apr 23 2014
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Apr 23, 2014 at 04:28:30PM +0000, Dicebot via Digitalmars-d wrote:
[...]

 Gosh now I finally know what researches to blame for my eyes bleeding
 upon most web site restylings (Facebook *caugh-caugh*). If anything it
 just shows that overall reading skills are decreasing and no one care
 about visitors with small fonts (me).


On the contrary, I find almost all websites have broken layouts because
I enforce a minimal font size of 16pt (I have a high-resolution screen)
-- they insist on font sizes that are far too small.  Usually makes me
override the site's style with my own custom-made one (or just move on
to the next site).



 But current HTML/CSS standards don't provide way to express sizes as
 percentage of screen width (as opposed to page window width), do they?


They provide sizes per font measurements, which is good enough for
implementing CPLs, no?


T

-- 
Time flies like an arrow. Fruit flies like a banana.
Apr 23 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote:

 On the contrary, I find almost all websites have broken layouts because
 I enforce a minimal font size of 16pt (I have a high-resolution screen)
 -- they insist on font sizes that are far too small.


This is why teams need some old codgers like me around. We don't see so good 
anymore, and need larger fonts.

The teeny-tiny fonts all come from people under 25 :-)


Ironically, the most unreadable web pages I've seen were on apple.com. Haven't 
looked at it recently, but they'd use a tiny font, and make it light gray 
letters on a white background. It was literally painful to try and read it.

The current winnah for unreadable text goes to meld Ubuntu 13.10. For some 
wretched reason, 'meld' under the new Ubuntu uses a font where the letters are 
about one pixel wide meaning it's nearly impossible to even see the colored
text.

Some day I'm going to pull a tape measure between my eyes and my monitor, and 
get some glasses optimized for that distance.
Apr 23 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/23/2014 2:12 PM, Walter Bright wrote:

 On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote:

 On the contrary, I find almost all websites have broken layouts because
 I enforce a minimal font size of 16pt (I have a high-resolution screen)
 -- they insist on font sizes that are far too small.


 This is why teams need some old codgers like me around. We don't see so
 good anymore, and need larger fonts.

 The teeny-tiny fonts all come from people under 25 :-)


I certainly won't disagree that small fonts can be hard to read, but on 
the other end, I've seen a lot of newer websites with gigantic fonts, 
and I find that painful to read as well.


 Ironically, the most unreadable web pages I've seen were on apple.com.
 Haven't looked at it recently, but they'd use a tiny font, and make it
 light gray letters on a white background. It was literally painful to
 try and read it.


Grey-on-white is ridiculously common and should be jailable offense. 
I'll never understand the the reasoning behind that readability destroyer.
Apr 23 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Apr 23, 2014 at 05:32:00PM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 4/23/2014 2:12 PM, Walter Bright wrote:

On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote:

On the contrary, I find almost all websites have broken layouts
because I enforce a minimal font size of 16pt (I have a
high-resolution screen) -- they insist on font sizes that are far
too small.


This is why teams need some old codgers like me around. We don't see
so good anymore, and need larger fonts.

The teeny-tiny fonts all come from people under 25 :-)




I can still see relatively well, but I prefer not having to squint at
the screen to read text on a webpage just because some clever web
designer decided that 6pt fonts are a good idea. That's why I configured
my browser to enforce a minimum font size of 14 pt (or was it 16pt?),
regardless of what the stylesheet says. It's the only way I could even
tolerate reading certain sites.



 I certainly won't disagree that small fonts can be hard to read, but
 on the other end, I've seen a lot of newer websites with gigantic
 fonts, and I find that painful to read as well.


Any examples?

Usually when I run into a site with (1) microscopic fonts, (2) giant
(often multicolored) fonts, (3) no whitespace, or (4) has more
ads/filler than content, my fingers have an almost instinctual ctrl-W
(close tab) response. Sometimes not even one word registers in my brain
before I move on to the next site.

In fact, I'm of the arrogant opinion that websites should not specify
ANY font size except a relative size to the browser's default, because
chances are, whatever size you choose will look horrible on *somebody*'s
device. Browsers come with a default (and user-configurable!) font size
for a reason. Web designers would be foolish to disregard that.



Ironically, the most unreadable web pages I've seen were on
apple.com.  Haven't looked at it recently, but they'd use a tiny
font, and make it light gray letters on a white background. It was
literally painful to try and read it.


 
 Grey-on-white is ridiculously common and should be jailable offense.
 I'll never understand the the reasoning behind that readability
 destroyer.


Worse yet, I've actually seen sites that use red on gray (or the other
way round -- it's too painful to recall). Or lime on turqoise. Or any of
various other horrible combinations. Aughh... my eyes hurt just thinking
about it... On the bright side, most sites that pick such colors usually
don't have any useful content to offer either, so the ctrl-W kneejerk
(fingerjerk?) fixes the problem quite quickly.


T

-- 
"No, John.  I want formats that are actually useful, rather than
over-featured megaliths that address all questions by piling on
ridiculous internal links in forms which are hideously over-complex." --
Simon St. Laurent on xml-dev
Apr 23 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:

 On Wed, Apr 23, 2014 at 05:32:00PM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 I certainly won't disagree that small fonts can be hard to read, but
 on the other end, I've seen a lot of newer websites with gigantic
 fonts, and I find that painful to read as well.


 Any examples?


Ugh, actually I wish I had some. I tend to run away from those sites too 
quickly to either remember them or bookmark for later ridicule. I should 
start bookmarking them though, for fun :)

Another thing I've seen that makes things literally painful to read is 
double-spacing. Double-spacing is needed in school so the instructor can 
mark comments (Assuming schools even do essays in hardcopy anymore?). 
Outside of school it just makes things hard to read.

Though I can't confirm, I always assumed such sites were probably trying 
too hard to be typographically proper. Either that or they assumed 
everyone was running on a 5 bazillion DPI monitor or some such.



 Usually when I run into a site with (1) microscopic fonts, (2) giant
 (often multicolored) fonts, (3) no whitespace, or (4) has more
 ads/filler than content, my fingers have an almost instinctual ctrl-W
 (close tab) response. Sometimes not even one word registers in my brain
 before I move on to the next site.


Incidentally, ugly rainbow text is also why I set my mail client to 
plaintext-only ages ago.



 In fact, I'm of the arrogant opinion that websites should not specify
 ANY font size except a relative size to the browser's default, because
 chances are, whatever size you choose will look horrible on *somebody*'s
 device. Browsers come with a default (and user-configurable!) font size
 for a reason. Web designers would be foolish to disregard that.


I agree. Unfortunately though, browsers haven't always has reasonable 
defaults, so people had to work around, so now it's all pretty much screwed.

Maybe what we need is a CSS for "sane-size-defaults: on;" which would 
provide a "reboot" of the whole default font sizes. That way, any pages 
that still assume the old broken defaults system and actively work 
around it won't break, but newer sites could finally start relying on 
sane user/browser/device-specific defaults.



 Grey-on-white is ridiculously common and should be jailable offense.
 I'll never understand the the reasoning behind that readability
 destroyer.


 Worse yet, I've actually seen sites that use red on gray (or the other
 way round -- it's too painful to recall). Or lime on turqoise. Or any of
 various other horrible combinations. Aughh... my eyes hurt just thinking
 about it... On the bright side, most sites that pick such colors usually
 don't have any useful content to offer either, so the ctrl-W kneejerk
 (fingerjerk?) fixes the problem quite quickly.


 From what I've seen, most of those really weird-colored ones were cases 
where I wouldn't necessarily expect the author to be good with styling. 
But grey-on-white gets used even by sites that *should* know better. 
GitHub was pretty bad with that a couple years ago.


contrast, so you often want something that's just a really dark grey. 
But still, a lot of sites take the softened-contrast thing too far.
Apr 24 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:

 I agree. Unfortunately though, browsers haven't always has 
 reasonable defaults, so people had to work around, so now it's 
 all pretty much screwed.

 Maybe what we need is a CSS for "sane-size-defaults: on;" which 
 would provide a "reboot" of the whole default font sizes.


The defaults in the original browsers were set a bit large 
(16px), so Safari decided to set them smaller for a while. That 
sucked. Nowadays you can just set the scaling of the body to 
87.5% of the default and get a reasonable size (14px).

What annoy me the most is non-promotional sites that set the body 
font-family to anything but the default sans-serif (which often 
happens to be pixel perfect, have good unicode support and is 
legible).
Apr 24 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 8:27 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 What annoy me the most is non-promotional sites that set the body
 font-family to anything but the default sans-serif (which often happens
 to be pixel perfect, have good unicode support and is legible).


Yea, I've seen some web documents written in really hard-to-read fonts.
Apr 24 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/24/2014 2:39 PM, Nick Sabalausky wrote:

 Yea, I've seen some web documents written in really hard-to-read fonts.



I've recently seen some academic research PDF's where the font is so small that 
even if I go full screen on them they are very hard to read. I don't get the 
reason for doing this. Are they trying to save paper or something?
Apr 24 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 I've recently seen some academic research PDF's where the font 
 is so small that even if I go full screen on them they are very 
 hard to read.


Some combinations of PDF readers and PDF files support reflow, so 
later you can also increase the zoom. Another solution is to buy 
a wider screen, now even wide ones are kind of cheap.



 I don't get the reason for doing this. Are they trying to save 
 paper or something?


They are often trying to save paper. Some conferences (and 
sometimes even some journals) set a maximum limit of pages for 
submitted papers.

Bye,
bearophile
Apr 24 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 25, 2014 at 01:54:29AM +0000, bearophile via Digitalmars-d wrote:

 Walter Bright:
 

I've recently seen some academic research PDF's where the font is so
small that even if I go full screen on them they are very hard to
read.


 
 Some combinations of PDF readers and PDF files support reflow, so
 later you can also increase the zoom. Another solution is to buy a
 wider screen, now even wide ones are kind of cheap.


I don't like wide screens that much, actually. I still prefer 4x3 aspect
ratio. I kinda agree with Nick that wide screens are more like
half-height screens. :-P



I don't get the reason for doing this. Are they trying to save paper
or something?


 
 They are often trying to save paper. Some conferences (and sometimes
 even some journals) set a maximum limit of pages for submitted papers.


[...]

You mean, they're trying to save on pages? I don't think the journal
publisher necessarily cares about *paper* per se, but more about the
cost of printing too many pages.


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It
is the customer who pays the wages. -- Henry Ford
Apr 24 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 10:07 PM, H. S. Teoh via Digitalmars-d wrote:

 I don't like wide screens that much, actually. I still prefer 4x3 aspect
 ratio. I kinda agree with Nick that wide screens are more like
 half-height screens. :-P


I've even seen companies actually trying to sell ~2:1 abominations. Even 
movies (which are perfectly fine in 16:9) are painful to watch in that 
god-awful ratio - even made "Batman Begins" difficult to watch. Luckily 
nobody seems dumb enough to reward those devices with actual purchases.
Apr 24 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/24/2014 6:54 PM, bearophile wrote:

 Some combinations of PDF readers and PDF files support reflow, so later you can
 also increase the zoom. Another solution is to buy a wider screen, now even
wide
 ones are kind of cheap.


Wider ones won't help. You'd need a taller one.
Apr 24 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 9:54 PM, bearophile wrote:

 Walter Bright:

 I don't get the reason for doing this. Are they trying to save paper
 or something?


 They are often trying to save paper. Some conferences (and sometimes
 even some journals) set a maximum limit of pages for submitted papers.


Don't they write them in Latex and then generate the PDF? You'd think 
it'd be trivial to generate the microscope version to send off to those 
who expect it, and then generate a proper one for actual reading. This 
isn't exactly 1970 typewriter-era, after all.
Apr 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 11:46:16PM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 4/24/2014 9:54 PM, bearophile wrote:

Walter Bright:

I don't get the reason for doing this. Are they trying to save paper
or something?


They are often trying to save paper. Some conferences (and sometimes
even some journals) set a maximum limit of pages for submitted
papers.


 
 Don't they write them in Latex and then generate the PDF? You'd think
 it'd be trivial to generate the microscope version to send off to
 those who expect it, and then generate a proper one for actual
 reading. This isn't exactly 1970 typewriter-era, after all.


True. In theory, you could make your LaTeX document flexible enough to
produce two very different outputs depending on the occasion.  I have
done this before -- the Turing-complete macro system makes this very
easy to do. Of course, it also suffers from the downsides of macro
systems: it's very easy to screw up and end up with completely garbled
output. :P (And, if not done properly, can lead to your document
becoming a write-only mess that even you don't remember how it works --
LaTeX is very much like a programming language.) Which probably explains
why most people don't do it. Hmph.

OTOH, I believe journals nowadays actually give you a LaTeX template
that you're supposed to follow, and they greatly frown upon submissions
that don't conform to that template. So people are less likely to fiddle
with stuff that they normally would otherwise.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and
over.
Apr 24 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/25/2014 12:00 AM, H. S. Teoh via Digitalmars-d wrote:

 OTOH, I believe journals nowadays actually give you a LaTeX template
 that you're supposed to follow, and they greatly frown upon submissions
 that don't conform to that template. So people are less likely to fiddle
 with stuff that they normally would otherwise.


I would think basic computing features like text editing, copy/paste, 
and filenames would make trivially short work of conforming to various 
templates upon submission, even for the less technically-inclined.
Apr 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 25, 2014 at 12:24:47AM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 4/25/2014 12:00 AM, H. S. Teoh via Digitalmars-d wrote:

OTOH, I believe journals nowadays actually give you a LaTeX template
that you're supposed to follow, and they greatly frown upon
submissions that don't conform to that template. So people are less
likely to fiddle with stuff that they normally would otherwise.


 
 I would think basic computing features like text editing, copy/paste,
 and filenames would make trivially short work of conforming to various
 templates upon submission, even for the less technically-inclined.


True, it's quite easy in LaTeX to split your document into multiple
files. One easy way to conform to different templates would be something
like:

publisher_template.tex:

	\documentclass{...}
	...	% whatever the publisher predefined
	\input{my_macros.tex}
	\begin{document}
	\input{content.tex}
	\end{document}

readable_template.tex:

	\documentclass{...}
	...	% sane formatting settings here
	\input{my_macros.tex}
	\begin{document}
	\input{content.tex}
	\end{document}

my_macros.tex:

	...	% any additional stuff you want in the preamble,
		% like \newcommand's, and so on.

content.tex:

	...	% put actual article body here

Then running `latex publisher_template.tex` will produce the document to
be submitted, `latex readable_template.tex` will produce a more readable
version.

I'm not sure if your average journal author is savvy enough to set this
up, though. I have the sinking suspicion that probably most of them know
just the bare minimum to make LaTeX produce some output, and don't
really care about doing things in a more sophisticated way.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need
before which you can't deliver after.
Apr 24 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/25/2014 1:06 AM, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Apr 25, 2014 at 12:24:47AM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 I would think basic computing features like text editing, copy/paste,
 and filenames would make trivially short work of conforming to various
 templates upon submission, even for the less technically-inclined.


 True, it's quite easy in LaTeX to split your document into multiple
 files. One easy way to conform to different templates would be something
 like:


[...]

 I'm not sure if your average journal author is savvy enough to set this
 up, though. I have the sinking suspicion that probably most of them know
 just the bare minimum to make LaTeX produce some output, and don't
 really care about doing things in a more sophisticated way.


Actually, I just meant:

- Edit "my_document.tex"
- Publisher requests special version
- Make needed changes, save as "my_document_publisherX.tex"

- Maybe update "my_document.tex" later on
- Same publisher requests the update
- Either copy/paste all non-template content into 
"my_document_publisherX.tex" or just make the same publisher-specific 
changes again.
- Or make the changes to "my_document_publisherX.tex" first and then 
update "my_document.tex".

Obviously not quite as quick and reliable as what a programmer might do, 
but still pretty damn trivial, and well within the abilities of any 
author. In fact, it's pretty much what nearly any "average Joe with MS 
Word" would do without even being told. And they manage to get by fine 
(much to my puzzlement, sometimes ;) ).
Apr 25 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
Another thing that kills me about the new "big picture up top,
scroll to gigantic say-nothing text below" fad....

The text below sounds like there might be some more learning to
do. So I try to click on the headers.... nothing happens. No see
more link.

Apparently "Feature rich: we have more features than anybody!" is
all they have to say. No explanation of what those features are.

<a href="this-makes-me-angry-because-it-sux">Hatred.</a>
Apr 24 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 24 April 2014 at 08:17:15 UTC, Nick Sabalausky wrote:

 As if <b> hasn't always implied the semantics of "emphasis" 
 anyway...not that anyone's ever had any real use for semantic 
 "which text is emphasized?" for any purpose besides "Should 
 this text be rendered in bold/italic or not?"

 Funny though...I've never heard any of the semantic-web-loving, 
 <b>/etc haters complain about things like Markdown ;)


I use semantic markup for emphasis where it's supported. Can't 
say I used markdown a lot, though I guess its semantics is more 
similar to that of semantic markup than visual markup, I can say 
wiki markup is.

On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:

 I agree. Unfortunately though, browsers haven't always has 
 reasonable defaults, so people had to work around, so now it's 
 all pretty much screwed.

 Maybe what we need is a CSS for "sane-size-defaults: on;" which 
 would provide a "reboot" of the whole default font sizes. That 
 way, any pages that still assume the old broken defaults system 
 and actively work around it won't break, but newer sites could 
 finally start relying on sane user/browser/device-specific 
 defaults.


I'm thinking more about some standardization of web skins, then 
people will choose their web skin of choice just like on desktop 
system, and sites will use that chosen skin to present content 
and layout.
Apr 24 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 9:59 AM, Kagamin wrote:

 On Thursday, 24 April 2014 at 08:17:15 UTC, Nick Sabalausky wrote:

 As if <b> hasn't always implied the semantics of "emphasis"
 anyway...not that anyone's ever had any real use for semantic "which
 text is emphasized?" for any purpose besides "Should this text be
 rendered in bold/italic or not?"

 Funny though...I've never heard any of the semantic-web-loving,
 <b>/etc haters complain about things like Markdown ;)


 I use semantic markup for emphasis where it's supported. Can't say I
 used markdown a lot, though I guess its semantics is more similar to
 that of semantic markup than visual markup, I can say wiki markup is.


Markdown:

*italic*
**bold**
**_bold and italic_**

Although it appears to implement those using <em> and <strong>, which 
strikes me as completely pointless and roundabout.



 I'm thinking more about some standardization of web skins, then people
 will choose their web skin of choice just like on desktop system, and
 sites will use that chosen skin to present content and layout.


Unfortunately that'll never happen: It's already hard enough to get 
*application* developers not to invent their own idiotic 
user-disrespecting skin (with poorly homespun controls).
Apr 24 2014
parent "Kagamin" <spam here.lot> writes:
On Thursday, 24 April 2014 at 21:48:46 UTC, Nick Sabalausky wrote:

 Markdown:

 *italic*
 **bold**
 **_bold and italic_**


That looks like semantic markup. Visual markup would be
/italic/
*bold*
_underlined_


 I'm thinking more about some standardization of web skins, 
 then people
 will choose their web skin of choice just like on desktop 
 system, and
 sites will use that chosen skin to present content and layout.


 Unfortunately that'll never happen: It's already hard enough to 
 get *application* developers not to invent their own idiotic 
 user-disrespecting skin (with poorly homespun controls).


It wouldn't prevent using custom styles, it would enable use of 
user preferences without rolling custom setting manager, what 
Alexandar is going to do.
Apr 25 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Wednesday, 23 April 2014 at 16:28:32 UTC, Dicebot wrote:

 *caugh-caugh*). If anything it just shows that overall reading 
 skills are decreasing and no one care about visitors with small 
 fonts (me). But current HTML/CSS standards don't provide way to 
 express sizes as percentage of screen width (as opposed to page 
 window width), do they?


Javascript libraries fill this gap: 
http://simplefocus.com/flowtype/
Apr 23 2014
prev sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 23/04/2014 5:28 PM, Dicebot wrote:

 Gosh now I finally know what researches to blame for my eyes bleeding
 upon most web site restylings (Facebook *caugh-caugh*).



Are you sure that your eyes aren't bleeding because your fonts are too 
small?

A...
Apr 24 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 24 April 2014 at 08:06:18 UTC, Alix Pexton wrote:

 On 23/04/2014 5:28 PM, Dicebot wrote:

 Gosh now I finally know what researches to blame for my eyes 
 bleeding
 upon most web site restylings (Facebook *caugh-caugh*).



 Are you sure that your eyes aren't bleeding because your fonts 
 are too small?

 A...


Considering the very same size 9 fonts are used as default 
everywhere else in my desktop system and it feels just fine.. 
yeah, you must be right. It must be small font and not weirdly 
scaled UI with 2/3 of screen space blank. Sure.
Apr 24 2014
next sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 24/04/2014 9:44 AM, Dicebot wrote:

 Considering the very same size 9 fonts are used as default everywhere
 else in my desktop system and it feels just fine.. yeah, you must be
 right. It must be small font and not weirdly scaled UI with 2/3 of
 screen space blank. Sure.


We must just be oppositesAt the distance I sit from my monitor 9pt type 
is vanishingly small, I can read it as I type it, but not once I've 
forgotten what it says. I couldn't work like that.

I find that most sites use fonts that are too small, I often zoom until 
what I want to read fills the screen at a reasonable line length. don't 
know for sure how big that makes it but its probably around 32pt.

Sites that have too much empty space around the text are often the ones 
that are kindest to zooming. others that try to fill the void tend to 
reflow at every step of zoom and get to very short lines very quickly.
Apr 24 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 08:21:04PM +0100, Alix Pexton via Digitalmars-d wrote:

 On 24/04/2014 9:44 AM, Dicebot wrote:

Considering the very same size 9 fonts are used as default everywhere
else in my desktop system and it feels just fine.. yeah, you must be
right. It must be small font and not weirdly scaled UI with 2/3 of
screen space blank. Sure.


 
 We must just be oppositesAt the distance I sit from my monitor 9pt
 type is vanishingly small, I can read it as I type it, but not once
 I've forgotten what it says. I couldn't work like that.
 
 I find that most sites use fonts that are too small, I often zoom
 until what I want to read fills the screen at a reasonable line
 length. don't know for sure how big that makes it but its probably
 around 32pt.


Glad to know I'm not the only one! :)



 Sites that have too much empty space around the text are often the
 ones that are kindest to zooming. others that try to fill the void
 tend to reflow at every step of zoom and get to very short lines very
 quickly.


I find it disappointing that after so many decades, we still haven't
solved the problem of fluid layout. I mean, it's not as though it's an
NP complete problem or something like that; in theory we *should*
already have algorithms for this sort of thing. Yet people still
continue clinging to outdated concepts about page layout.

In an ideal world, the webserver simply serves the content, and the
browser is the one that decides how to present it -- and the user
decides how the browser should present it. Ultimately, the user should
be in charge.


T

-- 
Verbing weirds language. -- Calvin (& Hobbes)
Apr 24 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 3:40 PM, H. S. Teoh via Digitalmars-d wrote:

 In an ideal world, the webserver simply serves the content, and the
 browser is the one that decides how to present it -- and the user
 decides how the browser should present it. Ultimately, the user should
 be in charge.


That's exactly how HTML used to work, but then the print folk and 
graphic designers came in and demanded total control.
Apr 24 2014
prev sibling parent Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 24/04/2014 9:44 AM, Dicebot wrote:

 Considering the very same size 9 fonts are used as default everywhere
 else in my desktop system and it feels just fine.. yeah, you must be
 right. It must be small font and not weirdly scaled UI with 2/3 of
 screen space blank. Sure.


We must just be opposites.

I tested. At the distance I sit from my monitor 9pt type is vanishingly 
small, I can read it as I type it, but not once I've forgotten what it 
says. I couldn't work like that, I certainly could not bare to browse 
the web like that.

I often zoom in on websites until what I want to read fills the screen 
at a reasonable line length. I don't know for sure how big that makes it 
but its probably between 24pt and 32pt. (When I'm coding I have my IDE 
set to 20pt.)

Sites that have too much empty space around the text are often the ones 
that are kindest to zooming. others that try to fill the void tend to 
reflow at every step of zoom and line lengths get ridiculously short as 
the filler expands.

I dislike empty space, but I'd rather a page were designed with a fixed 
maximum line length for readability and allow the reader to zoom, than 
with the objective of filling every pixel of screen with text.

For the record, I am quite severely dyslexic, and mildly myopic, but I 
don't believe my preference for large type is related to either.

A...
Apr 24 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu 
wrote:

 So I'd dlang.org to foster a behavior depending on the 
 available real estate, as follows:

 * Cap cpl at e.g. 110 on very large screens.

 * As the available width decreases, reduce cpl up to 60.

 * If cpl with sidebar falls below 60, remove the sidebar and 
 obtain e.g. 80 cpl.

 * As the available width reduces further, allow reduction down 
 to e.g. 35 cpl, and then require horizontal scrolling.


At some point you'll probably realize that the term "cpl" is not 
particularly meaningful in this context because:

1. you don't use a monofont and have to figure out what "cpl" is 
in "em" or "rem".

2. adults detect phrases, not characters, so any measurements are 
done on the wrong unit anyway.

3. quantitative human factors studies that go beyond your inate 
capabilites tend to be full of severe methodological flaws.

Waste of time.
Apr 23 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 1:53 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote:

 So I'd dlang.org to foster a behavior depending on the available real
 estate, as follows:

 * Cap cpl at e.g. 110 on very large screens.

 * As the available width decreases, reduce cpl up to 60.

 * If cpl with sidebar falls below 60, remove the sidebar and obtain
 e.g. 80 cpl.

 * As the available width reduces further, allow reduction down to e.g.
 35 cpl, and then require horizontal scrolling.


 At some point you'll probably realize that the term "cpl" is not
 particularly meaningful in this context because:

 1. you don't use a monofont and have to figure out what "cpl" is in "em"
 or "rem".


I'm talking averages.


 2. adults detect phrases, not characters, so any measurements are done
 on the wrong unit anyway.


For a given language (English in our case), the relationship translates 
into average words per line.


 3. quantitative human factors studies that go beyond your inate
 capabilites tend to be full of severe methodological flaws.


Uhm...


 Waste of time.


I doubt it.


Andrei
Apr 23 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 23:25:43 UTC, Andrei Alexandrescu 
wrote:

 1. you don't use a monofont and have to figure out what "cpl" 
 is in "em"
 or "rem".


 I'm talking averages.


It varies with the font used. :-P And if you use a webfont the 
rendering will be less legible than when you use a screen 
optimized system font. So if you want clarity, unicode coverage 
and performance you don't know which font you get. :-]


 For a given language (English in our case), the relationship 
 translates into average words per line.


Not necessarily… since groupings aren't neccessarily words. Also, 
you don't READ prose in programming documentation like a novel, 
if you are a proficient programmer. You scan, backtrack, read, 
scan, backtrack, read…


 3. quantitative human factors studies that go beyond your inate
 capabilites tend to be full of severe methodological flaws.


 Uhm...


Uhm what? Large sections of psychology are fundamentally flawed 
as a predictive science, it's primarily interpretative.

Measures are contextual. Reading is a skill, you are better at 
what you are used to. Besides, reading efficiency is less 
important than reading comfort.

If studies are off by 50% then that suggest that there are NO 
HOPE of significant results here.


 Waste of time.


 I doubt it.


You are better off setting something reasonable, test, modify, 
iterate. And if needed you can always provide a stylesheet 
switcher (takes 15 minute to implement).
Apr 24 2014
prev sibling parent "Kagamin" <spam here.lot> writes:
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu 
wrote:

 So I'd dlang.org to foster a behavior depending on the 
 available real estate, as follows:

 * Cap cpl at e.g. 110 on very large screens.

 * As the available width decreases, reduce cpl up to 60.

 * If cpl with sidebar falls below 60, remove the sidebar and 
 obtain e.g. 80 cpl.

 * As the available width reduces further, allow reduction down 
 to e.g. 35 cpl, and then require horizontal scrolling.


If the sidebar is not critical, then maybe get rid of it, why 
bother? If you get 100 cpl on sites without sidebar, then on 
sites with half page width dedicated for empty space, they would 
get content at 50 cpl - still in range.

I'm not against 100 cpl, I'm against page width and 1300px, that 
are much less meaningful values. In fact, that WCAG page displays 
for me at full page width and 100 cpl, and it has small 
stylesheet. Why not let user choose? All that complication also 
results in overblown stylesheets, which are unmanageable without 
a CSS preprocessor (yikes, just what they have there?). Why solve 
problem you created yourself?
Apr 25 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 4:12 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 1. visitors are likely to be familiar with one of those
 2. they might have figured out something that works
 3. you want to do at least what they do, but better


Good points.

IMO:


 http://www.rust-lang.org/


Too black-and-white.


 http://golang.org/


Too cluttered *and* too plain-white.


 https://www.dartlang.org/


This is a popular new style that I really, really dislike. The entry 
page basically amounts to one of those horribly useless "intro/entry" 
pages that used to be popular in the late 90's even though nobody liked 
them (*because* they were so completely useless). It's not quite *as* 
bad as those old intro pages, but it's only just *barely* better. 
They've dedicated their entire entry page to little more than a slogan. 
I hate pointless entry pages like that.

It's such a "trendy" style that I guarantee it's going to look dated 
within 5 years.


 https://www.python.org/


This is a much better, less useless, variant of the popular 
"dartlang.org" style above. It isn't bad, but I'm not sure D really 
needs to follow this style.
Apr 19 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 6:52 PM, Nick Sabalausky wrote:

 On 4/18/2014 4:12 PM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:


  > https://www.python.org/

 This is a much better, less useless, variant of the popular
 "dartlang.org" style above. It isn't bad, but I'm not sure D really
 needs to follow this style.


One very notable downside of this style is that it pretty much requires 
that mobile be handled separately with a completely different layout. I 
see no point in wasting effort maintaining dual designs (and providing 
such an inconsistent UX in the process) when you can just use one style 
that works fine on all devices.



 Apr 19 2014



prev sibling  parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/18/2014 2:56 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 Nice initiative, but the top bar looks a lot like adobe.com . I think
 something less corporate would be more suitable. What are you trying to
 communicate? A community or a corporation?


I had a brief thought of that too, but I quickly dismissed it because it 
really *isn't* corporate-looking...

I swear I'm not joking about this: *Real* corporate sites are:

1. Covered with obviously-stock photos of evenly-distributed 
easily-identifiable ethnicities (nothing mixed or ethnicly-ambiguous), 
with 50%/50%/0% gender ratio (if anything, biased towards black females 
with 90's "hip" curly-poofy hairstyles), all in suits with 
unrealistically gigantic "Gosh I *LOVE* working in IT and/or customer 
support call center" smiles.

2. *All* the text across the entire page is completely vacuous, highly 
subjective *at best*, and generally carries no real meaning whatsoever.

So while there are some corporate-like elements (flat shading, clean 
straight lines, limited saturated-colors palette - all of which are just 
as "modern" as they are "corporate") this mockup, overall, is definitely 
*not* very corporate-looking IMO.



 Apr 19 2014



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Saturday, 19 April 2014 at 22:38:31 UTC, Nick Sabalausky wrote:

 I had a brief thought of that too, but I quickly dismissed it 
 because it really *isn't* corporate-looking...


To me it looks like a typical start-up design. It does not peek 
my interest in the 2 seconds you need to tell me that this is an 
active programming community with many participants and that I 
can join the ranks if I want to. I find the current the design to 
peak my interest because it isn't typical, but there are better 
ways to do it. I think golang and rust do that well, by luring 
you into a tutorial.

Push github links, tutorial links, download and latest activity 
with member names.

  I also find the big highly saturated logo in desaturated context 
annoying. It draws too much attention and makes the design 
unbalanced. That's what you do for branding. Put that saturation 
on where you want people to look. The download/start tour/etc 
buttons.


 2. *All* the text across the entire page is completely vacuous, 
 highly subjective *at best*, and generally carries no real 
 meaning whatsoever.


Thats one thing I dislike about the current frontpage. 
Wall-of-text does not make me curious. I do like the ability to 
execute D code though.



 Apr 20 2014



 next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


Just to stating some basic observations to avoid noise.

1. Graphic design  of frontpages should follow the principle: 
"form follows function".

2. Mimicry of the visual style used on adobe.com will make you 
look good, and somehow familiar, but it is not going to make you 
stand out.

3. The current D population is not your primary target. Your 
primary target is people who stumble over dlang.org while 
searching on Google and spend 2 seconds glancing over your stuff.

4. You need to communicate effectively before they move on. Peek 
their interest. Create enough curiosity to sell them your main 
points.

Looking good is great, but subordinate to peaking curiosity and 
reflecting that you have something unique to sell.



 Apr 20 2014



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


I just had a non-alcohol beer, so I think I'll rant some more 
while I'm at it:

WHY don't the community front the story of Walter Bright's D 
vision on the front-page? It is a wonderful selling point that 
appeals to geeks and make them interested:

1. Competent: Wrote a well known C++ compiler
2. Shared vision: Created D out of frustration with C++
3. Exciting: performance is key
4. Motives: Altruistic
5. A-political: open source, commercial friendly and international
6. Has a following: active community, community driven
7. Jump in: Open to participation

The current front page is too anonymous to make me interested. 
The original (long time ago) website was more personal and there 
was a sense of "personal drive" to it. It gave me a "Dang, that's 
cool. That Walter dude is brave enough to take on C++. Gotta see 
what this is all about." feeling.

A personal design with a personal vision is more attractive to me 
than a "professional design" (which actually is just a fashion 
statement) with longwinded descriptions that lacks focus (nobody 
actually read those, they want to see code samples).

Not to say that there is a right or wrong way to go about web 
site design, and a blend of the various approaches is probably 
the right thing.

As an example I'll point out that this norwegian site has a very 
good ranking at Google:

http://www.arngren.net/

It is not because it has wonderful design… ;-)



 Apr 20 2014



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Sun, 20 Apr 2014 03:33:46 -0400, Ola Fosheim Gr=C3=B8stad  =

<ola.fosheim.grostad+dlang gmail.com> wrote:


 It does not peek my interest


Sorry, don't take this the wrong way, it's my OCD, not your fault ;)

But it's "pique"

-Steve



 Apr 21 2014



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 21 April 2014 at 12:21:20 UTC, Steven Schveighoffer 
wrote:

 Sorry, don't take this the wrong way, it's my OCD, not your 
 fault ;)


Of course it is my fault! I always thought it was "peak", thanks 
for extending my vocabulary. Now I have figure out not only when 
to use "peek" or "peak", but also have to consider "pique"… :-/


 But it's "pique"


In my own tounge it sounds like the norwegian word for male 
genitals… but I am liberal. I can say "pique":

P I Q U E !

(That's french…?)



 Apr 21 2014



prev sibling next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/18/2014 10:04 AM, Aleksandar Ruzicic wrote:

 I have also tried to design something myself (although I'm not a
 designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks better
 (or at least more modern) than the current design.


 So, what do you guys think?


I'm normally very skeptical and critical of "staying modern" (and 
regarding someone's mention of Win8 - I find Win8 downright UGLY) - 
However...I really like your design, quite a lot.

As long as it's:

- A normal reflowing layout (not a static fixed-width one or an 
auto-rescaling one)

- Doesn't require JS (optional JS enhancements are fine)

- Works reasonably well on mobile *including* a complete and total lack 
of that "no zooming allowed" abomination that seems so popular these 
days (As far as I'm concerned, full user-controlled scaling is 
*mandatory* for good usability on tiny hand-held devices, especially on 
these "modern" capacitive ones incapable of registering presses from 
anything more accurate than a blunt finger - or for anyone with less 
than 20/20 eyesight)



 Apr 18 2014



 next sibling parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/18/2014 6:07 PM, Nick Sabalausky wrote:

 As long as it's:


[...]


Meant to say: Nothing against the current design, but as long as yours 
is (those things), then I'd be very happy to see your design used.



 Apr 18 2014



prev sibling  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote:

 On 4/18/2014 10:04 AM, Aleksandar Ruzicic wrote:

 I have also tried to design something myself (although I'm not 
 a
 designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better
 (or at least more modern) than the current design.


 So, what do you guys think?


 I'm normally very skeptical and critical of "staying modern" 
 (and regarding someone's mention of Win8 - I find Win8 
 downright UGLY) - However...I really like your design, quite a 
 lot.

 As long as it's:

 - A normal reflowing layout (not a static fixed-width one or an 
 auto-rescaling one)


Of course.


 - Doesn't require JS (optional JS enhancements are fine)


I was told you would oppose usage of JavaScript. :)
But as I've said already I plan on using JavaScript to enhance 
things a bit only, site would function normally with JavaScript 
unavailable/disabled.


 - Works reasonably well on mobile *including* a complete and 
 total lack of that "no zooming allowed" abomination that seems 
 so popular these days (As far as I'm concerned, full 
 user-controlled scaling is *mandatory* for good usability on 
 tiny hand-held devices, especially on these "modern" capacitive 
 ones incapable of registering presses from anything more 
 accurate than a blunt finger - or for anyone with less than 
 20/20 eyesight)


Agreed. And it shouldn't just work reasonably well on mobile, it 
must work flawlessly well :)



 Apr 19 2014



  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/19/2014 3:48 AM, Aleksandar Ruzicic wrote:

 On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote:

 As long as it's:

 - A normal reflowing layout (not a static fixed-width one or an
 auto-rescaling one)


 Of course.


Cool.


 - Doesn't require JS (optional JS enhancements are fine)


 I was told you would oppose usage of JavaScript. :)


Heh, yea, I'm kinda well-known for that 'round these parts ;)


 But as I've said already I plan on using JavaScript to enhance things a
 bit only, site would function normally with JavaScript
 unavailable/disabled.


Yea, that's cool. Honestly, even I do that too.


 - Works reasonably well on mobile *including* a complete and total
 lack of that "no zooming allowed" abomination that seems so popular
 these days (As far as I'm concerned, full user-controlled scaling is
 *mandatory* for good usability on tiny hand-held devices, especially
 on these "modern" capacitive ones incapable of registering presses
 from anything more accurate than a blunt finger - or for anyone with
 less than 20/20 eyesight)


 Agreed. And it shouldn't just work reasonably well on mobile, it must
 work flawlessly well :)


Heh, personally, I think working "flawlessly well" on mobile pretty much 
requires a PalmOS device (long since defunct), but that's a whole other 
twenty rants and would only make me feel old ;)



 Apr 19 2014



prev sibling next sibling parent reply 1100110 <0b1100110 gmail.com>  writes:


On 4/18/14, 9:04, Aleksandar Ruzicic wrote:

 Hello,

 I've been D enthusiast for couple of years now (but I do not participate
 much in discussions here, although I read forums almost daily), and I
 keep telling people about D and how awesome it is.


[snip]

 So, what do you guys think?




 -- Aleksandar



I REALLY like the new look.  I think it's about time to change the 
website up a little bit for the reasons listed above.

It looks 'clean'.  Go for it!



 Apr 18 2014



  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:

 On 4/18/14, 9:04, Aleksandar Ruzicic wrote:

 Hello,

 I've been D enthusiast for couple of years now (but I do not 
 participate
 much in discussions here, although I read forums almost 
 daily), and I
 keep telling people about D and how awesome it is.


 [snip]

 So, what do you guys think?




 -- Aleksandar



 I REALLY like the new look.  I think it's about time to change 
 the website up a little bit for the reasons listed above.

 It looks 'clean'.  Go for it!


Thanks! I'm planning to start working on this as soon as I get 
approval from Walter/Andrei, and as most of people who answered 
here are agreed that redesign would be a good thing I hope they 
wouldn't oppose..



 Apr 19 2014



 next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote:

 On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:

 It looks 'clean'.  Go for it!


 Thanks! I'm planning to start working on this as soon as I get approval
 from Walter/Andrei, and as most of people who answered here are agreed
 that redesign would be a good thing I hope they wouldn't oppose..


Although I empathize with not wanting to put the full work into 
something if there's a chance it may just get rejected at the last step, 
this is unfortunately the sort of thing that really needs to be in a 
full working pull request before you're likely to get any final official 
approval. Not getting an outright up-front objections is kinda the 
closest thing D has to pre-approval for large changes like this.



 Apr 19 2014



 next sibling parent  "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Saturday, 19 April 2014 at 23:21:15 UTC, Nick Sabalausky wrote:

 On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote:

 On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:

 It looks 'clean'.  Go for it!


 Thanks! I'm planning to start working on this as soon as I get 
 approval
 from Walter/Andrei, and as most of people who answered here 
 are agreed
 that redesign would be a good thing I hope they wouldn't 
 oppose..


 Although I empathize with not wanting to put the full work into 
 something if there's a chance it may just get rejected at the 
 last step, this is unfortunately the sort of thing that really 
 needs to be in a full working pull request before you're likely 
 to get any final official approval. Not getting an outright 
 up-front objections is kinda the closest thing D has to 
 pre-approval for large changes like this.


Ok then. Given that I haven't received up-front rejections I'll 
start working on this and hope it wouldn't be in vain. :)



 Apr 19 2014



prev sibling  parent  Martin Nowak <code dawg.eu>  writes:


On 04/20/2014 01:21 AM, Nick Sabalausky wrote:

 Although I empathize with not wanting to put the full work into
 something if there's a chance it may just get rejected at the last step,
 this is unfortunately the sort of thing that really needs to be in a
 full working pull request before you're likely to get any final official
 approval. Not getting an outright up-front objections is kinda the
 closest thing D has to pre-approval for large changes like this.


Getting more feedback during early development would help.
Not sure how to get there, there is little traffic on dmd-internals, 
DIPs rarely result from collaboration and pull requests only allow to 
criticize almost finished work.



 Apr 24 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:

 I'm planning to start working on this as soon as I get approval
 from Walter/Andrei, and as most of people who answered here are agreed
 that redesign would be a good thing I hope they wouldn't oppose..


Let's do it. Thank you very much! -- Andrei



 Apr 20 2014



 next sibling parent  "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu 
wrote:

 On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:

 I'm planning to start working on this as soon as I get approval
 from Walter/Andrei, and as most of people who answered here 
 are agreed
 that redesign would be a good thing I hope they wouldn't 
 oppose..


 Let's do it. Thank you very much! -- Andrei


Great! I'll start tonight! :)



 Apr 21 2014



prev sibling  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu 
wrote:

 On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:

 I'm planning to start working on this as soon as I get approval
 from Walter/Andrei, and as most of people who answered here 
 are agreed
 that redesign would be a good thing I hope they wouldn't 
 oppose..


 Let's do it. Thank you very much! -- Andrei


Just one question, would it be okay to depend on node.js/npm to 
manage dependencies (i.e. CSS/JS frameworks) and build CSS/JS 
files?

As I'd use Sass for styling, which must be translated to CSS (I'd 
use node-sass package witch doesn't require ruby), and browserify 
to have Common-JS modules..



 Apr 21 2014



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/21/14, 8:48 AM, Aleksandar Ruzicic wrote:

 On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote:

 On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:

 I'm planning to start working on this as soon as I get approval
 from Walter/Andrei, and as most of people who answered here are agreed
 that redesign would be a good thing I hope they wouldn't oppose..


 Let's do it. Thank you very much! -- Andrei


 Just one question, would it be okay to depend on node.js/npm to manage
 dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?


Ionno. Not an expert, but I'd say the fewer dependencies the better. Add 
them only if it's onerously hard to get work done without and/or if 
their payoff is large.


 As I'd use Sass for styling, which must be translated to CSS (I'd use
 node-sass package witch doesn't require ruby), and browserify to have
 Common-JS modules..


I think you should be fine with ddoc macros instead of Sass.


Andrei



 Apr 21 2014



  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Monday, 21 April 2014 at 18:35:04 UTC, Andrei Alexandrescu 
wrote:

 On 4/21/14, 8:48 AM, Aleksandar Ruzicic wrote:

 On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu 
 wrote:

 On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:

 I'm planning to start working on this as soon as I get 
 approval
 from Walter/Andrei, and as most of people who answered here 
 are agreed
 that redesign would be a good thing I hope they wouldn't 
 oppose..


 Let's do it. Thank you very much! -- Andrei


 Just one question, would it be okay to depend on node.js/npm 
 to manage
 dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?


 Ionno. Not an expert, but I'd say the fewer dependencies the 
 better. Add them only if it's onerously hard to get work done 
 without and/or if their payoff is large.


Understood.



 As I'd use Sass for styling, which must be translated to CSS 
 (I'd use
 node-sass package witch doesn't require ruby), and browserify 
 to have
 Common-JS modules..


 I think you should be fine with ddoc macros instead of Sass.


 Andrei


I'm not sure if it is smart to use simple text macro processing 
system as a replacement for full-featured DSL such is Sass. And I 
don't think that some features available (and really useful!) in 
Sass are even possible with Ddoc. For example branching with  if, 
composing of various style sets to optimal CSS (Sass has  extend 
directive for this).
Also, Ddoc can't minify resulting CSS which is something that is 
considered good practice (serve gzipped minified JS/CSS), so some 
external tool must be used for that. With node-sass we can get 
all that and more (i.e. source maps)..



 Apr 21 2014



 next sibling parent reply David Gileadi <gileadis NSPMgmail.com>  writes:


On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:

 I'm not sure if it is smart to use simple text macro processing system
 as a replacement for full-featured DSL such is Sass. And I don't think
 that some features available (and really useful!) in Sass are even
 possible with Ddoc. For example branching with  if, composing of various
 style sets to optimal CSS (Sass has  extend directive for this).
 Also, Ddoc can't minify resulting CSS which is something that is
 considered good practice (serve gzipped minified JS/CSS), so some
 external tool must be used for that. With node-sass we can get all that
 and more (i.e. source maps)..


A little searching turned up libsass.org which apparently is the native 
library that node.js uses for its implementation. So if there's an 
objection to full node.js (or if vibe.d is used) then perhaps the native 
library would do.



 Apr 21 2014



 next sibling parent  "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:

 On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:

 I'm not sure if it is smart to use simple text macro 
 processing system
 as a replacement for full-featured DSL such is Sass. And I 
 don't think
 that some features available (and really useful!) in Sass are 
 even
 possible with Ddoc. For example branching with  if, composing 
 of various
 style sets to optimal CSS (Sass has  extend directive for 
 this).
 Also, Ddoc can't minify resulting CSS which is something that 
 is
 considered good practice (serve gzipped minified JS/CSS), so 
 some
 external tool must be used for that. With node-sass we can get 
 all that
 and more (i.e. source maps)..


 A little searching turned up libsass.org which apparently is 
 the native library that node.js uses for its implementation. So 
 if there's an objection to full node.js (or if vibe.d is used) 
 then perhaps the native library would do.


Yep, forgot to mention that libsass (used by node-sass) is 
cross-platform C library. Thanks!



 Apr 21 2014



prev sibling  parent  "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:

 On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:

 I'm not sure if it is smart to use simple text macro 
 processing system
 as a replacement for full-featured DSL such is Sass. And I 
 don't think
 that some features available (and really useful!) in Sass are 
 even
 possible with Ddoc. For example branching with  if, composing 
 of various
 style sets to optimal CSS (Sass has  extend directive for 
 this).
 Also, Ddoc can't minify resulting CSS which is something that 
 is
 considered good practice (serve gzipped minified JS/CSS), so 
 some
 external tool must be used for that. With node-sass we can get 
 all that
 and more (i.e. source maps)..


 A little searching turned up libsass.org which apparently is 
 the native library that node.js uses for its implementation. So 
 if there's an objection to full node.js (or if vibe.d is used) 
 then perhaps the native library would do.


Oh, I forgot to mention that I'm not advocating the use of 
node.js to serve dlang.org (I'm all for vibe.d route!), just to 
use node.js packages I'm used to (i.e. gulp[1], gulp-sass[2] and 
gulp-browserify[3]) that ease me in working with front-end 
projects.

[1] https://www.npmjs.org/package/gulp
[2] https://www.npmjs.org/package/gulp-sass
[3] https://www.npmjs.org/package/gulp-browserify



 Apr 21 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:

 I'm not sure if it is smart to use simple text macro processing system
 as a replacement for full-featured DSL such is Sass. And I don't think
 that some features available (and really useful!) in Sass are even
 possible with Ddoc.


Well you'd be surprised. But the same guideline applies - the tool needs 
to offer enough payoff to justify the dependency.

I confess getting a bit uncomfortable about adding new dependencies at 
this point. We depend on dpl-docs already, and the tool was difficult to 
install and broke from one dmd release to the next. Sönke was nice and 
proactive about it, but he's an active member of the community. If we 
find issues with tooling coming from the outside - and we will - we're 
on our own. It would help if many people in the community are fluent 
with them.

Adding a tool right now that has overlapping functionality with 
ddoc/dpl-docs, and that is relatively unknown within the community 
sounds like a tall order.


Andrei



 Apr 21 2014



  parent reply Jacob Carlborg <doob me.com>  writes:


On 21/04/14 23:23, Andrei Alexandrescu wrote:


 I confess getting a bit uncomfortable about adding new dependencies at
 this point. We depend on dpl-docs already, and the tool was difficult to
 install and broke from one dmd release to the next. Sönke was nice and
 proactive about it, but he's an active member of the community. If we
 find issues with tooling coming from the outside - and we will - we're
 on our own. It would help if many people in the community are fluent
 with them.


I've used Sass a lot. Although not via node.


 Adding a tool right now that has overlapping functionality with
 ddoc/dpl-docs, and that is relatively unknown within the community
 sounds like a tall order.


Sass doesn't overlap with ddoc.

-- 
/Jacob Carlborg



 Apr 21 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 4/21/14, 11:51 PM, Jacob Carlborg wrote:

 On 21/04/14 23:23, Andrei Alexandrescu wrote:


 I confess getting a bit uncomfortable about adding new dependencies at
 this point. We depend on dpl-docs already, and the tool was difficult to
 install and broke from one dmd release to the next. Sönke was nice and
 proactive about it, but he's an active member of the community. If we
 find issues with tooling coming from the outside - and we will - we're
 on our own. It would help if many people in the community are fluent
 with them.


 I've used Sass a lot. Although not via node.


Good to know, thanks.


 Adding a tool right now that has overlapping functionality with
 ddoc/dpl-docs, and that is relatively unknown within the community
 sounds like a tall order.


 Sass doesn't overlap with ddoc.


I'm clearly outta my depth here, basing myself off of giving 
http://sass-lang.com/guide a couple minutes. From what I can tell here's 
how ddoc matches up sass features:

Pre-processing: yes
Variables: yes
Nesting: no
Partials, Import: somewhat (by passing several ddoc files to dmd)
Mixins: yes
Extend/Inheritance: no
Operators: no

I'm glad to see a revamp of dlang.org happening. Again if the added 
tools bring great advantages with them, fine. But we can't add 
dependencies carelessly and only for minor convenience.

Let me ask Aleksandar again: we already depend on dpl-docs since 
recently. Is it helping/competing with the new tools you plan to add?


Andrei



 Apr 22 2014



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 2014-04-22 18:38, Andrei Alexandrescu wrote:


 I'm clearly outta my depth here, basing myself off of giving
 http://sass-lang.com/guide a couple minutes. From what I can tell here's
 how ddoc matches up sass features:

 Pre-processing: yes
 Variables: yes
 Nesting: no
 Partials, Import: somewhat (by passing several ddoc files to dmd)
 Mixins: yes
 Extend/Inheritance: no
 Operators: no

 I'm glad to see a revamp of dlang.org happening. Again if the added
 tools bring great advantages with them, fine. But we can't add
 dependencies carelessly and only for minor convenience.


I'm not going to argue which is best. But since I started to use Sass, I 
see no reason to use plain CSS. Even just for nesting, which is the most 
used feature I've seen people use, I think it's worth it. Although, I'm 
using Ruby on Rails which comes bundled with Sass.

-- 
/Jacob Carlborg



 Apr 22 2014



  parent  "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Tuesday, 22 April 2014 at 19:34:08 UTC, Jacob Carlborg wrote:

 On 2014-04-22 18:38, Andrei Alexandrescu wrote:


 I'm clearly outta my depth here, basing myself off of giving
 http://sass-lang.com/guide a couple minutes. From what I can 
 tell here's
 how ddoc matches up sass features:

 Pre-processing: yes
 Variables: yes
 Nesting: no
 Partials, Import: somewhat (by passing several ddoc files to 
 dmd)
 Mixins: yes
 Extend/Inheritance: no
 Operators: no

 I'm glad to see a revamp of dlang.org happening. Again if the 
 added
 tools bring great advantages with them, fine. But we can't add
 dependencies carelessly and only for minor convenience.


 I'm not going to argue which is best. But since I started to 
 use Sass, I see no reason to use plain CSS. Even just for 
 nesting, which is the most used feature I've seen people use, I 
 think it's worth it. Although, I'm using Ruby on Rails which 
 comes bundled with Sass.


I'm no Rails (or Ruby) developer but I use Sass for all my
styling needs for a long time now. It was the only reason I had
ruby installation on my computer (nowdays I use libsass, so no
ruby.. yey).

I find it really easy to setup and use thanks to npm and
node-sass package (I prefer not to manually compile my tools),
and build tools like grunt and (now more popular) gulp really
make the life easier for front-end projects (which I still have
to do every once in a while). I just hope we will have such
ecosystem one day in D (with help of gulp).



 Apr 22 2014



prev sibling  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Tuesday, 22 April 2014 at 16:38:04 UTC, Andrei Alexandrescu 
wrote:

 On 4/21/14, 11:51 PM, Jacob Carlborg wrote:

 On 21/04/14 23:23, Andrei Alexandrescu wrote:


 I confess getting a bit uncomfortable about adding new 
 dependencies at
 this point. We depend on dpl-docs already, and the tool was 
 difficult to
 install and broke from one dmd release to the next. Sönke was 
 nice and
 proactive about it, but he's an active member of the 
 community. If we
 find issues with tooling coming from the outside - and we 
 will - we're
 on our own. It would help if many people in the community are 
 fluent
 with them.


 I've used Sass a lot. Although not via node.


 Good to know, thanks.


 Adding a tool right now that has overlapping functionality 
 with
 ddoc/dpl-docs, and that is relatively unknown within the 
 community
 sounds like a tall order.


 Sass doesn't overlap with ddoc.


 I'm clearly outta my depth here, basing myself off of giving 
 http://sass-lang.com/guide a couple minutes. From what I can 
 tell here's how ddoc matches up sass features:

 Pre-processing: yes
 Variables: yes
 Nesting: no
 Partials, Import: somewhat (by passing several ddoc files to 
 dmd)
 Mixins: yes
 Extend/Inheritance: no
 Operators: no

 I'm glad to see a revamp of dlang.org happening. Again if the 
 added tools bring great advantages with them, fine. But we 
 can't add dependencies carelessly and only for minor 
 convenience.

 Let me ask Aleksandar again: we already depend on dpl-docs 
 since recently. Is it helping/competing with the new tools you 
 plan to add?


 Andrei


It's not competing with Sass. Sass would make it easier for me to 
faster write needed styling and also more importantly to have 
style files easy to maintain later (I had worked few times with 
monolithic 3000+ lines long CSS files and can attest that it's 
much easier to work with nice hierarchy of small SCSS files).

I can surely do without Sass and use plain CSS but to keep it 
maintainable I would need to split it to multiple files and would 
need a tool to concat those later to the target CSS (this can be 
done with cat but it's non-standard on windows) and then I would 
need a tool to minify that CSS.

These are simple tools, and they can be written from scratch in D 
(which I would like to do, but then I won't be working on 
redesign while those are done).

If I would use Sass, I would not only get really nice and 
powerful DSL to write styles in but I would get tools to concat 
and minify CSS.

As I've said in message to Dicebot I would not use npm as it 
would be bad marketing, but I would really like to use libsass 
(sassc - the compiler, to be precise, libsass is a library used 
by sassc) which written in C.

If that's too much dependencies I'll have to go with plain CSS 
files.

And I've already decided to use Make instead of gulp (a npm 
packaged build tool for node.js).

The only thing that remains is JavaScript minifyer. I have tried 
almost all of them, Google Closure Compiler, YUICompressor, 
jsmin, UglifyJS and in my experience UgifyJS[1] is definitely the 
best tool for that task (closure compiler can get your slimmer 
files but you must stick to Google's rules of writing and 
annotating your code, which I find too limiting).

The only problem with UglifyJS is that it's a Node.js 
library/tool...
So I don't know what to do about that. Sure, there are online 
versions of both Closure Compiler and UglifyJS but they cannot be 
integrated in build system (well, not without requirement of 
internet connection).

I wonder if DMDScript's parser could be used to write JS minifier 
in D. This is actually something I would really like to look into 
but there is definitely not small amount of work needed to 
develop a tool like that. So it will have to wait, sadly.

So, as I'm not aware of any native good JS minifing tool I'd skip 
that step for now. We can optimize that later (anyway, I'll keep 
JS usage on bare minimum).

The only question yet remaining is if I can depend on sassc[2] or 
not?


[1] https://github.com/mishoo/UglifyJS
[2] https://github.com/hcatlin/sassc



 Apr 22 2014



 next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


I wrote a css expander that has a little bit of SASS features.

Previously it was hidden in my html.d on my misc. github, but I 
just now made it a standalone program in a separate repo:

https://github.com/adamdruppe/cssexpand

Check out the demo input file
https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css

and demo result file
https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css

to get an idea of what it does.



 Apr 22 2014



 next sibling parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:

 I wrote a css expander that has a little bit of SASS features.

 Previously it was hidden in my html.d on my misc. github, but I 
 just now made it a standalone program in a separate repo:

 https://github.com/adamdruppe/cssexpand

 Check out the demo input file
 https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css

 and demo result file
 https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css

 to get an idea of what it does.


Wow, this looks really nice! It has variables, mixins, nested 
selectors and includes.. That's all I need!

Only.. any chance of making ¤ prefix configurable via cmdline 
params? :)
Ideally I would use   as prefix, but that may interfere with CSS 
 -rules (I see you have CssAtRule class to handle those), so I'd 
use some character that's easier to type like $ (but that is used 
for parent selector in upcoming CSS 4)...



 Apr 22 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic 
wrote:

 Wow, this looks really nice! It has variables, mixins, nested 
 selectors and includes.. That's all I need!


Yea, I wrote this several years ago before even knowing about 
sass based on what annoyed me about CSS and it looks like me and 
the sass people had a lot of the same complaints because our 
results are almost compatible. I think sass does a better job 
with calculations but meh, I just use box-sizing: border-box and 
then I don't care as much about calculations anymore anyway!


 Ideally I would use   as prefix, but that may interfere with 
 CSS  -rules (I see you have CssAtRule class to handle those), 
 so I'd use some character that's easier to type like $ (but 
 that is used for parent selector in upcoming CSS 4)...


Yeah, that's why I picked the weird symbol, I wanted something 
that wasn't going to be used anywhere else in normal CSS so it 
wouldn't conflict. (The implementation here is stupid simple: it 
just does indexOf this symbol and then replaces it. The denesting 
is a more complete css parser, but the macros replacement is 
plain text search.)


Anyway, I updated the github to allow $ to be used.



 Apr 23 2014



  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/23/2014 9:11 AM, Adam D. Ruppe wrote:

 On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic wrote:

 Wow, this looks really nice! It has variables, mixins, nested
 selectors and includes.. That's all I need!


 Yea, I wrote this several years ago before even knowing about sass based
 on what annoyed me about CSS and it looks like me and the sass people
 had a lot of the same complaints because our results are almost
 compatible. I think sass does a better job with calculations but meh, I
 just use box-sizing: border-box and then I don't care as much about
 calculations anymore anyway!


"box-sizing: border-box" is proof of what I've said all along: Microsoft 
got the box model right in old IEs, and W3C got it wrong.



 Apr 23 2014



prev sibling next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com>  writes:


On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:

 I wrote a css expander that has a little bit of SASS features.

 Previously it was hidden in my html.d on my misc. github, but I 
 just now made it a standalone program in a separate repo:

 https://github.com/adamdruppe/cssexpand

 Check out the demo input file
 https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css

 and demo result file
 https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css

 to get an idea of what it does.


Any chance to get this separated out just for the css part of it? 
And onto the dub repository?
I would really like to use this for Cmsed!
And ugh can I change that weird symbol to '$'?



 Apr 22 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole 
wrote:

 Any chance to get this separated out just for the css part of 
 it?


Hmm, you know, maybe that wouldn't be too hard. I thought it used 
dom.d's css parser but it actually doesn't! So I could probably 
write a little css module that doesn't depend on the others 
(except color.d).

I might work on it tonight.


 And ugh can I change that weird symbol to '$'?


Use std.array.replace to change it before passing to the macro 
system. There's just the problem then that $ is a fairly common 
symbol so it will conflict with some other stuff.



 Apr 23 2014



  parent  "Rikki Cattermole" <alphaglosined gmail.com>  writes:


On Wednesday, 23 April 2014 at 13:22:02 UTC, Adam D. Ruppe wrote:

 On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole 
 wrote:

 Any chance to get this separated out just for the css part of 
 it?


 Hmm, you know, maybe that wouldn't be too hard. I thought it 
 used dom.d's css parser but it actually doesn't! So I could 
 probably write a little css module that doesn't depend on the 
 others (except color.d).

 I might work on it tonight.


Thanks! I will be looking forward to it on the dub repository.


 And ugh can I change that weird symbol to '$'?


 Use std.array.replace to change it before passing to the macro 
 system. There's just the problem then that $ is a fairly common 
 symbol so it will conflict with some other stuff.


Okay, doesn't look too bad of a deal that.



 Apr 23 2014



prev sibling  parent reply "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:

 I wrote a css expander that has a little bit of SASS features.

 Previously it was hidden in my html.d on my misc. github, but I 
 just now made it a standalone program in a separate repo:

 https://github.com/adamdruppe/cssexpand

 Check out the demo input file
 https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css

 and demo result file
 https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css

 to get an idea of what it does.


This is awesome. I think I might try it out for my next web-dev 
contract. If it could be put on code.dlang.org that would be 
awesome.

I've always been tempted to use Sass or similar, but this seems 
like the simple tool I've actually wanted.



 Apr 23 2014



 next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/23/2014 5:55 PM, John Colvin wrote:

 On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:

 I wrote a css expander that has a little bit of SASS features.

 Previously it was hidden in my html.d on my misc. github, but I just
 now made it a standalone program in a separate repo:

 https://github.com/adamdruppe/cssexpand

 Check out the demo input file
 https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css

 and demo result file
 https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css

 to get an idea of what it does.


 This is awesome. I think I might try it out for my next web-dev
 contract. If it could be put on code.dlang.org that would be awesome.

 I've always been tempted to use Sass or similar, but this seems like the
 simple tool I've actually wanted.


SCSS has always been more interesting to me than SASS, but yea, this 
seems to pretty much be an independently-developed equivalent to SCSS, 
which is pretty cool.



 Apr 23 2014



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 23 April 2014 at 22:12:08 UTC, Nick Sabalausky 
wrote:

 SCSS has always been more interesting to me than SASS, but yea, 
 this seems to pretty much be an independently-developed 
 equivalent to SCSS, which is pretty cool.


The funny thing is I wrote this thing a few years ago, 2011 I 
think, and I've been using it on several sites too. It's just 
been hidden from the general public in my misc. github :P

There's also a javascript macro expander which adds foreach to 
that language via text macro hidden away in that html.d as well...



 Apr 23 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 24/04/14 00:12, Nick Sabalausky wrote:


 SCSS has always been more interesting to me than SASS, but yea, this
 seems to pretty much be an independently-developed equivalent to SCSS,
 which is pretty cool.


Technically, Sass is the name of the language. It provides two syntaxes, 
SASS and SCSS. SCSS seems to be the preferred one. It's used as the 
default for examples on the web site, Ruby on Rails uses this by 
default. It's also a superset of CSS.

-- 
/Jacob Carlborg



 Apr 23 2014



prev sibling  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote:

 If it could be put on code.dlang.org that would be awesome.


http://code.dlang.org/packages/cssexpand



 Apr 23 2014



 next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com>  writes:


On Wednesday, 23 April 2014 at 23:17:02 UTC, Adam D. Ruppe wrote:

 On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote:

 If it could be put on code.dlang.org that would be awesome.


 http://code.dlang.org/packages/cssexpand


Can we have it as a library? Instead of as only an executable? 
Aka no main function.



 Apr 23 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole 
wrote:

 Can we have it as a library?


css.d in there has the lib code now with my other html stuff 
stripped out so it has fewer dependencies. Can dub just use it 
without using the little main file?

Note btw that this code is *brutally* slow and should be done 
ahead of time or at least aggressively cached; if you regenerate 
the file on each request you'll be surprised by how much cpu time 
it wastes.

The implementation is pretty much a brute force string search in 
a replace loop.



 Apr 24 2014



 next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com>  writes:


On Thursday, 24 April 2014 at 14:42:44 UTC, Adam D. Ruppe wrote:

 On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole 
 wrote:

 Can we have it as a library?


 css.d in there has the lib code now with my other html stuff 
 stripped out so it has fewer dependencies. Can dub just use it 
 without using the little main file?


Ugh it can yes. But when you set the target type it definitely 
cannot.

You probably want a dub.json file like this:

{
	"name": "cssexpand",
	"description": "A CSS expansion program",
	"authors": ["Adam D. Ruppe"],
	"homepage": "https://github.com/adamdruppe/cssexpand",
	"license": "BSL-1.0",
	"dependencies": {
		"cssexpand:library": "~master"
	},
	"subPackages": [
		{
			"name": "tool",
			"dependencies": {
				"cssexpand:library": "~master"
			},
			"mainSourceFile": "src/cssexpand.d",
			"targetType": "executable"
		},
		{
			"name": "library",
			"sourceFiles": ["src/css.d", "src/color.d"],
			"targetType": "library"
		}
	]
}

Defaults a library. To run the tool its basically:
dub run cssexpand:tool toolargs...
Or you can swap them, up to you.


 Note btw that this code is *brutally* slow and should be done 
 ahead of time or at least aggressively cached; if you 
 regenerate the file on each request you'll be surprised by how 
 much cpu time it wastes.


Lets not go into how much javascript code I'm generating in Cmsed 
;) So not a worry.


 The implementation is pretty much a brute force string search 
 in a replace loop.





 Apr 24 2014



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Thursday, 24 April 2014 at 15:53:13 UTC, Rikki Cattermole 
wrote:

 You probably want a dub.json file like this:


I added the configurations Sonke suggested, see if it works now.



 Apr 24 2014



prev sibling  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org>  writes:


Am 24.04.2014 16:42, schrieb Adam D. Ruppe:

 On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole wrote:

 Can we have it as a library?


 css.d in there has the lib code now with my other html stuff stripped
 out so it has fewer dependencies. Can dub just use it without using the
 little main file?


This should automatically yield two configurations - "application" and 
"library":

{
	"name": "cssexpand",
	"description": "A CSS expansion program",
	"authors": ["Adam D. Ruppe"],
	"homepage": "https://github.com/adamdruppe/cssexpand",
	"license": "BSL-1.0",
	"mainSourceFie":"src/cssexpand.d"
}

Running DUB directly on cssexpand will build the executable by default 
and using it as a dependency will cause it to be build it as a library.



 Apr 24 2014



  parent  =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org>  writes:


Am 24.04.2014 17:59, schrieb Sönke Ludwig:

 Am 24.04.2014 16:42, schrieb Adam D. Ruppe:

 On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole wrote:

 Can we have it as a library?


 css.d in there has the lib code now with my other html stuff stripped
 out so it has fewer dependencies. Can dub just use it without using the
 little main file?


 This should automatically yield two configurations - "application" and
 "library":

 ...


Meh, unfortunately it requires to add the tow configurations manually:

{
	"name": "cssexpand",
	"description": "A CSS expansion program",
	"authors": ["Adam D. Ruppe"],
	"homepage": "https://github.com/adamdruppe/cssexpand",
	"license": "BSL-1.0",
	"mainSourceFile": "src/cssexpand.d",
	"configurations": [
		{
			"name": "application",
			"targetType": "executable"
		},
		{
			"name": "library",
			"targetType": "library",
			"excludedSourceFiles": ["src/cssexpand.d"]
		}
	]
}


BTW, no need to keep both, dub.json and package.json. If you want to 
stay compatible with old DUB versions, just use package.json, it will 
still be supported for new versions as well.



 Apr 24 2014



prev sibling  parent reply "Martin Nowak" <code dawg.eu>  writes:


On Wednesday, 23 April 2014 at 23:17:02 UTC, Adam D. Ruppe wrote:

 On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote:

 If it could be put on code.dlang.org that would be awesome.


 http://code.dlang.org/packages/cssexpand


Nice, thanks a lot. How much effort would it be to turn this into
a full SCSS compiler?
There is also a C project to draw from.
https://github.com/hcatlin/libsass

I think it would make a great addition to our D web stack.



 Apr 24 2014



  parent reply "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Thursday, 24 April 2014 at 07:59:20 UTC, Martin Nowak wrote:

 Nice, thanks a lot. How much effort would it be to turn this 
 into a full SCSS compiler?


Hmm, looking at the sass webpage, I think I could do some of the 
features but prolly not all and with a different syntax. So it 
wouldn't work for a full scss compiler.

If you want that, just use that C library or the ruby original.


My thingy is really just a generic text macro system with an 
extension that kinda understands css syntax and simply aims to be 
good enough for me. I can add to it but since it is good enough 
for me already, I don't have a pressing desire to go all the way. 
(As you might have heard on irc, I started a new job a couple 
weeks ago tho.... and it is a Ruby on Rails thing, so who knows, 
maybe I'll use the sass in that and find something I like enough 
to spend the time cloning it, but so far I use sass as just a 
substitute for my own cssexpand.)


Below is my impression of the sass docs.

Looks like the two big things they offer that I don't are 
inheritance and math.

Inheritance might be easy, I parse it out anyway so a referencing 
thingy could do that, sass calls that  extend. Math is something 
I avoided because it isn't terribly useful IMO and getting the 
units right isn't easy. What's 1em / 16px? Depends on the font 
size... which depends on the whole dynamic cascade.

Perhaps a unit mismatch could just issue an error though, 
sidestepping all that. So a little dimensional analysis!

We have some different syntax details though, like their variable 
assignment vs my set macro and the parent selector referencing in 
nested things is different.

Actually, the sass way of & might be a bit better than mine. For 
example, in mine:

a {
   :hover { color: red; }
}

expands into:

a {}
a:hover { color: red; }

If you wanted to reference a child with a pseudoclass, you'd have 
to do:

a {
   *:hover { color: red; }
}

then then gets you

a *:hover { ... }



Similarly, to add a class to the parent, mine does:

a {
   \&.foo {
   }
}

expands to a.foo {}


Something sass does that mine does NOT do is:

a {
   body & {}
}

which expands into body a {} and that's potentially useful. I 
think I'll add that.


* * *


I've done the import thing before but I don't think it was in 
css.d, I think I did that in the work app's proprietary file.

I do support  media rules but only on the outer level. sass also 
supports them inside a nested thing. That's kinda useful.

* * *

Looping and such? Yikes. I think I actually do support looping 
via one of the macros, but the syntax is pretty different.



 Apr 24 2014



  parent reply Jacob Carlborg <doob me.com>  writes:


On 2014-04-24 16:19, Adam D. Ruppe wrote:


 Hmm, looking at the sass webpage, I think I could do some of the
 features but prolly not all and with a different syntax. So it wouldn't
 work for a full scss compiler.


Sass really has some advanced features. It's possible to create a 
function in Ruby which you can call from Sass.

-- 
/Jacob Carlborg



 Apr 24 2014



  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Thursday, 24 April 2014 at 18:46:35 UTC, Jacob Carlborg wrote:

 Sass really has some advanced features. It's possible to create 
 a function in Ruby which you can call from Sass.


Yeah, going that far definitely isn't feasible. But I don't think 
there's a need for that either.

and besides you can always add a macro function to my thing in D 
too (that's how the color things work anyway)



 Apr 24 2014



prev sibling  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/22/2014 5:47 PM, Aleksandar Ruzicic wrote:

 and would need a
 tool to concat those later to the target CSS (this can be done with cat
 but it's non-standard on windows)


FWIW, on windows:

type input1.txt > output.txt
type input2.txt >> output.txt
type input3.txt >> output.txt



 Apr 22 2014



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 21 April 2014 at 15:48:45 UTC, Aleksandar Ruzicic 
wrote:

 On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu 
 wrote:

 On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:

 I'm planning to start working on this as soon as I get 
 approval
 from Walter/Andrei, and as most of people who answered here 
 are agreed
 that redesign would be a good thing I hope they wouldn't 
 oppose..


 Let's do it. Thank you very much! -- Andrei


 Just one question, would it be okay to depend on node.js/npm to 
 manage dependencies (i.e. CSS/JS frameworks) and build CSS/JS 
 files?

 As I'd use Sass for styling, which must be translated to CSS 
 (I'd use node-sass package witch doesn't require ruby), and 
 browserify to have Common-JS modules..


I think it is very important to dogfood here and add any 
currently missing dependencies as dub packages instead.



 Apr 21 2014



  parent reply Jacob Carlborg <doob me.com>  writes:


On 21/04/14 23:33, Dicebot wrote:


 I think it is very important to dogfood here and add any currently
 missing dependencies as dub packages instead.


Unless we can use libsass, I would say it's not very productive to 
implement a new Sass compiler, just to avoid a dependency.

-- 
/Jacob Carlborg



 Apr 21 2014



 next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:

 Unless we can use libsass, I would say it's not very productive 
 to implement a new Sass compiler, just to avoid a dependency.


I never use css macros-tools, regular template libraries are 
usually better (e.g. jinja2 allows me to execute python 
expressions if needed). With current browsers the CSS is getting 
much more streamlined too and the worst browser bugs require 
javascript detection anyway so macros don't cut it.

If you use static fallbacks then dynamic CSS calc() expressions 
are starting to become useful (lacking on Safari 5 and some 
Android browsers).

For javascript I strongly suggest using the very efficient and 
typesafe Closure compiler. It has a  good optimizer, dead code 
elimination and tight minimization. And it requires no 
install-dependencies since it is available as a REST web service:

http://closure-compiler.appspot.com/home

https://developers.google.com/closure/

Closure type annotations are in comments, so the annotated 
javascript code runs as regular javascript.

Ola.



 Apr 22 2014



  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-04-22 09:56, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 I never use css macros-tools, regular template libraries are usually
 better (e.g. jinja2 allows me to execute python expressions if needed).
 With current browsers the CSS is getting much more streamlined too and
 the worst browser bugs require javascript detection anyway so macros
 don't cut it.


I usually use these languages together with Ruby on Rails. With the 
assets pipeline in RoR it's possible to pipe several pre-processors 
together. Erb (Embedded Ruby) -> Sass -> CSS.

-- 
/Jacob Carlborg



 Apr 22 2014



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:

 On 21/04/14 23:33, Dicebot wrote:


 I think it is very important to dogfood here and add any 
 currently
 missing dependencies as dub packages instead.


 Unless we can use libsass, I would say it's not very productive 
 to implement a new Sass compiler, just to avoid a dependency.


I think using libsass is superior to using node/npm based 
dependency. Using pretty much anything from node.js 
infrastructure will be a big marketing hit for vibe.d (being its 
direct competitor in D world).



 Apr 22 2014



  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Tuesday, 22 April 2014 at 12:27:23 UTC, Dicebot wrote:

 On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:

 On 21/04/14 23:33, Dicebot wrote:


 I think it is very important to dogfood here and add any 
 currently
 missing dependencies as dub packages instead.


 Unless we can use libsass, I would say it's not very 
 productive to implement a new Sass compiler, just to avoid a 
 dependency.


 I think using libsass is superior to using node/npm based 
 dependency. Using pretty much anything from node.js 
 infrastructure will be a big marketing hit for vibe.d (being 
 its direct competitor in D world).


I see what you mean. I get that it wouldn't be good marketing so 
I decided not to use npm.

Although I would really like if we could do dub install -g 
<package> to distribute tools, like you can with npm..



 Apr 22 2014



  parent  "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 22 April 2014 at 21:21:13 UTC, Aleksandar Ruzicic 
wrote:

 On Tuesday, 22 April 2014 at 12:27:23 UTC, Dicebot wrote:

 On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg 
 wrote:

 On 21/04/14 23:33, Dicebot wrote:


 I think it is very important to dogfood here and add any 
 currently
 missing dependencies as dub packages instead.


 Unless we can use libsass, I would say it's not very 
 productive to implement a new Sass compiler, just to avoid a 
 dependency.


 I think using libsass is superior to using node/npm based 
 dependency. Using pretty much anything from node.js 
 infrastructure will be a big marketing hit for vibe.d (being 
 its direct competitor in D world).


 I see what you mean. I get that it wouldn't be good marketing 
 so I decided not to use npm.

 Although I would really like if we could do dub install -g 
 <package> to distribute tools, like you can with npm..


You can do `dub fetch package; dub run package` AFAIR for 
packages that are applications. Though it does not make any sense 
to add something that is not a D  project to dub, such a popular 
thing as sass compiler must have own package, whatever distro 
dlang web server runs on.



 Apr 23 2014



prev sibling  parent reply Martin Nowak <code dawg.eu>  writes:


On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:

 Just one question, would it be okay to depend on node.js/npm to manage
 dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

 As I'd use Sass for styling, which must be translated to CSS (I'd use
 node-sass package witch doesn't require ruby), and browserify to have
 Common-JS modules..


Why do you want to write the whole CSS yourself? Isn't something like 
bootstrap more appropriate for the task?



 Apr 22 2014



 next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/22/2014 6:26 PM, Martin Nowak wrote:

 On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:

 Just one question, would it be okay to depend on node.js/npm to manage
 dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

 As I'd use Sass for styling, which must be translated to CSS (I'd use
 node-sass package witch doesn't require ruby), and browserify to have
 Common-JS modules..


 Why do you want to write the whole CSS yourself? Isn't something like
 bootstrap more appropriate for the task?


Apparently they can't even manage make basic links work properly:

http://getbootstrap.com/examples/starter-template/

How anyone can manage to fuck up <a href="...">...</a> is beyond me.



 Apr 22 2014



 next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 23/04/14 00:57, Nick Sabalausky wrote:


 Apparently they can't even manage make basic links work properly:

 http://getbootstrap.com/examples/starter-template/

 How anyone can manage to fuck up <a href="...">...</a> is beyond me.


What's fucked up with the links?

-- 
/Jacob Carlborg



 Apr 22 2014



  parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/23/2014 2:34 AM, Jacob Carlborg wrote:

 On 23/04/14 00:57, Nick Sabalausky wrote:


 Apparently they can't even manage make basic links work properly:

 http://getbootstrap.com/examples/starter-template/

 How anyone can manage to fuck up <a href="...">...</a> is beyond me.


 What's fucked up with the links?


They don't work.

But...maybe they're only intended to be single-page-only examples? (Now 
that I think about it...)

If so, then I must have misunderstood the examples. The fact that 
they're all pointing to different anchor links threw me off and made me 
assume they were supposed to be functional. (I'm accustomed to blank 
zero-length anchors being used to indicate "intentionally non-functional 
placeholder link".)

But I have noticed a lot of the sites that use anchor links to switch to 
completely different pages are basically broken. Since the very 
*beginning* of HTML, links have always been downright trivial to 
implement, and have always been considerably *easier* to *not* require 
JS. It's pretty much the single simplest, easiest, most fundamental 
thing in HTML. And yet, more than a decade now after <a onclick="..."> 
linking inexplicably appeared, some people are *still* trying to 
implement links using JS. It's insane.

However, you'll have to pardon that little rant. When I posted that 
"Apparently they can't even manage make basic links work properly", I 
swear it wasn't my intention to do another JS-rant. Coming from me, JS 
rants are pretty much redundant at this point ;)



 Apr 23 2014



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Wed, Apr 23, 2014 at 06:08:52PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]

 But I have noticed a lot of the sites that use anchor links to switch
 to completely different pages are basically broken. Since the very
 *beginning* of HTML, links have always been downright trivial to
 implement, and have always been considerably *easier* to *not* require
 JS. It's pretty much the single simplest, easiest, most fundamental
 thing in HTML. And yet, more than a decade now after <a onclick="...">
 linking inexplicably appeared, some people are *still* trying to
 implement links using JS. It's insane.


[...]

I'm still amazed at the number of news sites that have non-functional
links the moment you disable JS. I had been running my browser with JS
turned on by default for many years, until sometime in the last few
years I got so sick of JS eating up CPU, memory, causing needless
browser slowdowns, popping up unwanted ads and nag dialogs, that now I'm
back to JS being off by default, and only (grudgingly) enabled for a
handful of specific sites that actually *need* it. It's amazing how much
faster the web suddenly became, overnight. And it's equally amazing how
many links stop working without JS. It boggles the mind... doesn't HTML
have a built-in link tag for that very purpose?!

Another new fad nowadays seems to be CSS popups that need JS to make
them go away. My usual reaction to that is to close the tab and move on.
Or, if I'm feeling particularly tolerant that day, switch to user
stylesheet mode (i.e., completely disregard the site's CSS and use my
own), and just scour the raw text for the real content (which usually
occupies, oh, 20% of the total text on the page -- apparently nowadays
minimizing your S/N ratio is in, providing useful content is out).
Doesn't fix the JS link issue, though, but so far, I've decided that
it's not worth the bother to find out what's behind such non-working
links -- esp. since Google will readily give me pages upon pages of
other places where I can get similar information! >:-)

 

 However, you'll have to pardon that little rant. When I posted that
 "Apparently they can't even manage make basic links work properly", I
 swear it wasn't my intention to do another JS-rant. Coming from me, JS
 rants are pretty much redundant at this point ;)


JS rants are fun. ;-)


T

-- 
We've all heard that a million monkeys banging on a million typewriters
will eventually reproduce the entire works of Shakespeare.  Now, thanks
to the Internet, we know this is not true. -- Robert Wilensk



 Apr 23 2014



  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


(Argh! Accidentally emailed this to digitalmars-d puremagic.com twice! 
Actually posting to NG now...)

On 4/23/2014 6:48 PM, H. S. Teoh via Digitalmars-d wrote:

 until sometime in the last few
 years I got so sick of JS eating up CPU, memory, causing needless
 browser slowdowns, popping up unwanted ads and nag dialogs, that now I'm
 back to JS being off by default, and only (grudgingly) enabled for a
 handful of specific sites that actually *need* it. It's amazing how much
 faster the web suddenly became, overnight.


That's why I do it! That plus the lack of modal CSS pop-in windows. 
(Seriously, no sooner do the browsers finally kill off popups, but then 
overzealous designers go replacing them with *modal* versions! And these 
new ones break basic browser functionality even *more*.)

The *truly* amazing thing is that many of those slow-with-JS sites are 
using JS/AJAX specifically *because* they actually believe it makes 
their site faster (I bet many of them are probably running on Node.js or 
PHP, too). Always, of course, based on the same half-baked, 
never-tested, but oft-repeated theory that reducing a few fractions of a 
kilobyte by doing partial page-reloads actually makes the web noticeably 
faster (yea right).

Shit, even in the days before 14.4 modems, let alone 56k or broadband, 
transferring the actual HTML was practically nothing, it was the 
occasional use of an image or two that slowed things down - *because 
those take a heck of a lot more bytes than HTML*. Even today, one 
gravitar image, one "share on site x" logo, or one stock photo of a 
model pretending to be an overjoyed IT worker, and *all* the 
partial-HTML savings are completely blown several times over. Not to 
mention all the extra CSS/HTML/JS used for rigging up a 
partial-reloading Web 2.0 "experience" in the first place.

And then there's sites that perform these performance "enhancing" AJAX 
requests *on initial page load*, which is just the definition of irony.



 And it's equally amazing how
 many links stop working without JS. It boggles the mind... doesn't HTML
 have a built-in link tag for that very purpose?!


Exactly. Speaking of which...

[Link Warning: Language and tone are probably NSFW, NSF-GitHub-Workers, 
and NSF-Humanity ;) ]

http://semitwist.com/articles/article/view/making-a-link-or-what-the-fuck-is-wrong-with-github-s-developers


 Another new fad nowadays seems to be CSS popups that need JS to make
 them go away. My usual reaction to that is to close the tab and move on.
 Or, if I'm feeling particularly tolerant that day, switch to user
 stylesheet mode (i.e., completely disregard the site's CSS and use my
 own), and just scour the raw text for the real content


I love this FF extension:

https://adblockplus.org/en/elemhidehelper

If I can't get rid of the garbage with that, the site's not worth 
spending another second on. I won't be bothered to even *think* about 
some poorly-made site's CSS, let alone touch any custom stylesheets.



 (which usually
 occupies, oh, 20% of the total text on the page -- apparently nowadays
 minimizing your S/N ratio is in, providing useful content is out).


Yup. Makes me miss "markup".

But then I go back to my own site, type <b></b> instead of <span 
class="something-that-implicitly-says-font-weight-bold-in-the-css"></span>, 
and all is well. Bonus points for me whenever <b> offends anyone's sense 
of "proper" HTML. :)

As if <b> hasn't always implied the semantics of "emphasis" anyway...not 
that anyone's ever had any real use for semantic "which text is 
emphasized?" for any purpose besides "Should this text be rendered in 
bold/italic or not?"

Funny though...I've never heard any of the semantic-web-loving, <b>/etc 
haters complain about things like Markdown ;)



 esp. since Google will readily give me pages upon pages of
 other places where I can get similar information! >:-)


Yea that's a big thing, too. So many designers actually believing their 
site is so special that people won't just move on or that being 
hitech-elitist won't hurt their site.



 JS rants are fun. ;-)


Heh, yea, it's an addiction :)



 Apr 24 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 24/04/14 00:08, Nick Sabalausky wrote:


 They don't work.

 But...maybe they're only intended to be single-page-only examples? (Now
 that I think about it...)


Yes. Bootstrap won't touch your links with JavaScript, unless you tell 
it to.


 If so, then I must have misunderstood the examples. The fact that
 they're all pointing to different anchor links threw me off and made me
 assume they were supposed to be functional. (I'm accustomed to blank
 zero-length anchors being used to indicate "intentionally non-functional
 placeholder link".)


Yeah, I don't know why they do that.


 But I have noticed a lot of the sites that use anchor links to switch to
 completely different pages are basically broken. Since the very
 *beginning* of HTML, links have always been downright trivial to
 implement, and have always been considerably *easier* to *not* require
 JS. It's pretty much the single simplest, easiest, most fundamental
 thing in HTML. And yet, more than a decade now after <a onclick="...">
 linking inexplicably appeared, some people are *still* trying to
 implement links using JS. It's insane.


I hate that as well. Sometimes I come to a page, with JS disabled, and 
it's completely blank. Then my thought process goes something like this: 
"Hmm, is it loaded. Yes, strange. Oh right I've disabled JavaScript. 
What is this pieces of crap, can't they design a web site without JS".


 However, you'll have to pardon that little rant. When I posted that
 "Apparently they can't even manage make basic links work properly", I
 swear it wasn't my intention to do another JS-rant. Coming from me, JS
 rants are pretty much redundant at this point ;)


No worries :)

-- 
/Jacob Carlborg



 Apr 23 2014



prev sibling  parent  "Martin Nowak" <code dawg.eu>  writes:


 http://getbootstrap.com/examples/starter-template/

 How anyone can manage to fuck up <a href="...">...</a> is 
 beyond me.


Nick what are you talking about? They referenced some anchors in
their example page and that works.



 Apr 22 2014



prev sibling  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Tuesday, 22 April 2014 at 22:26:39 UTC, Martin Nowak wrote:

 On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:

 Just one question, would it be okay to depend on node.js/npm 
 to manage
 dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

 As I'd use Sass for styling, which must be translated to CSS 
 (I'd use
 node-sass package witch doesn't require ruby), and browserify 
 to have
 Common-JS modules..


 Why do you want to write the whole CSS yourself? Isn't 
 something like bootstrap more appropriate for the task?


I would use Foundation[1] instead of Bootstrap.


[1] http://foundation.zurb.com/



 Apr 22 2014



 next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/22/2014 7:29 PM, Aleksandar Ruzicic wrote:

 On Tuesday, 22 April 2014 at 22:26:39 UTC, Martin Nowak wrote:

 Why do you want to write the whole CSS yourself? Isn't something like
 bootstrap more appropriate for the task?


 I would use Foundation[1] instead of Bootstrap.


 [1] http://foundation.zurb.com/


Eww. Font size and image scaling should *not* be a function of window 
size. That's just...yuck. Let the system determine it's own appropriate 
base font size.

And it's all in that horrible, ugly, "giant sized, yet minimal content 
and maximal blank space" style that's so inexplicably popular with the 
latest batches of web startups.

*shudder*



 Apr 22 2014



  parent reply "Martin Nowak" <code dawg.eu>  writes:


 Eww. Font size and image scaling should *not* be a function of 
 window size. That's just...yuck. Let the system determine it's 
 own appropriate base font size.

 And it's all in that horrible, ugly, "giant sized, yet minimal 
 content and maximal blank space" style that's so inexplicably 
 popular with the latest batches of web startups.

 *shudder*


Yeah, let's have a page like Peter Norvig (http://norvig.com). 
It's all about the content after all and if that is good the rest 
doesn't matter.



 Apr 22 2014



 next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


On Wednesday, 23 April 2014 at 06:47:58 UTC, Martin Nowak wrote:

 Yeah, let's have a page like Peter Norvig (http://norvig.com). 
 It's all about the content after all and if that is good the 
 rest doesn't matter.


There's a middle ground here.



 Apr 23 2014



prev sibling  parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/23/2014 2:47 AM, Martin Nowak wrote:

 Eww. Font size and image scaling should *not* be a function of window
 size. That's just...yuck. Let the system determine it's own
 appropriate base font size.

 And it's all in that horrible, ugly, "giant sized, yet minimal content
 and maximal blank space" style that's so inexplicably popular with the
 latest batches of web startups.

 *shudder*


 Yeah, let's have a page like Peter Norvig (http://norvig.com). It's all
 about the content after all and if that is good the rest doesn't matter.


I didn't say style was irrelevent. I only said that there should 
actually *be* content.



 Apr 23 2014



  parent  "Martin Nowak" <code dawg.eu>  writes:


 Yeah, let's have a page like Peter Norvig (http://norvig.com). 
 It's all
 about the content after all and if that is good the rest 
 doesn't matter.


 I didn't say style was irrelevent. I only said that there 
 should actually *be* content.


Sorry for the irony :), indeed fluffy sites without content are 
useless.
Reminds me of http://vimeo.com/89527215.



 Apr 23 2014



prev sibling  parent reply "Martin Nowak" <code dawg.eu>  writes:


 I would use Foundation[1] instead of Bootstrap.


 [1] http://foundation.zurb.com/


Whatever gets the job done. I haven't yet worked with Foundation, 
but it looks reasonable. Maybe we can limit the SCSS dependency 
by checking in the rendered CSS, so only people working on the 
style would need a sass compiler.
One remark though, try to stay away from heavy client-side JS, 
dlang.org is mostly a static website and anything that makes you 
wait 5s for the site to be rendered misses the point.



 Apr 23 2014



  parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Wednesday, 23 April 2014 at 07:02:50 UTC, Martin Nowak wrote:

 I would use Foundation[1] instead of Bootstrap.


 [1] http://foundation.zurb.com/


 Whatever gets the job done. I haven't yet worked with 
 Foundation, but it looks reasonable. Maybe we can limit the 
 SCSS dependency by checking in the rendered CSS, so only people 
 working on the style would need a sass compiler.
 One remark though, try to stay away from heavy client-side JS, 
 dlang.org is mostly a static website and anything that makes 
 you wait 5s for the site to be rendered misses the point.


I was thinking of that too, but I used this approach on one of 
previous projects (both, SCSS and generated CSS files were under 
git) and it just gave me headache as the coworker was changing 
CSS and committing those changes which leaved SCSS and CSS files 
out of sync. But we could easily just agree not to do it, and 
state that we don't accept pull requests that have direct changes 
in CSS.



 Apr 23 2014



  parent  "Martin Nowak" <code dawg.eu>  writes:


 Maybe we can limit the SCSS dependency by checking in the 
 rendered CSS, so only people working on the style would need a 
 sass compiler.





 I was thinking of that too, but I used this approach on one of 
 previous projects (both, SCSS and generated CSS files were 
 under git) and it just gave me headache as the coworker was 
 changing CSS and committing those changes which leaved SCSS and 
 CSS files out of sync.


Obviously not the way to do it.


 But we could easily just agree not to do it, and state that we 
 don't accept pull requests that have direct changes in CSS.


I think this will work out nice, css doesn't change very often.



 Apr 23 2014



prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com>  writes:


On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 So, what do you guys think?
 -- Aleksandar


I do agree that the design of the current site is rather dated. I 
rather like your new proposed design as well. One thing that 
could be nicer is the search bar being a button to click. It's 
standard now to just make it an input of type search with 
place-holder text now, which is faster and more useable. Even 
better, it could be automatically focused on when you load the 
(documentation) page so you can immediately start typing to look 
up an API / language feature.

People who go directly to the homepage are likely coming to check 
out what D is or why they should use it (which the homepage 
shows), find a download button (which could still be improved 
upon), or search the documentation (which is still a few clicks 
away). I'd argue that most people are going for the third option 
since you don't need to download often and people just checking 
it out don't return frequently to check it out again. Having an 
immediate search field, ideally with autofocus, makes finding 
documentation a very easy task.

A prominent download button immediately visible on the home page 
rather than the top nav-bar would be an improvement as well. 
Practically every site with something to download does this, for 
good reason. It's one of the first things that should jump out at 
you when you view the site, making it as little effort as 
possible to commit to at least downloading the installer (see 
Dart, Python, Rust, Go, Ruby, etc). The longer / more effort it 
takes to do something, the less likely people are to try it 
unless they're already very convinced it's something they need.



 Apr 18 2014



 next sibling parent reply "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Saturday, 19 April 2014 at 00:08:06 UTC, Kapps wrote:

 On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
 wrote:

 So, what do you guys think?
 -- Aleksandar


 I do agree that the design of the current site is rather dated. 
 I rather like your new proposed design as well. One thing that 
 could be nicer is the search bar being a button to click. It's 
 standard now to just make it an input of type search with 
 place-holder text now, which is faster and more useable. Even 
 better, it could be automatically focused on when you load the 
 (documentation) page so you can immediately start typing to 
 look up an API / language feature.


It sure looks like a button and it wouldn't be a button. It would 
be a regular text (search) input field (something that would be 
apparent as soon as you hover it and get that I-beam cursor over 
it) that would expand on click/focus (no JS needed there, don't 
worry Nick!).



 People who go directly to the homepage are likely coming to 
 check out what D is or why they should use it (which the 
 homepage shows), find a download button (which could still be 
 improved upon), or search the documentation (which is still a 
 few clicks away). I'd argue that most people are going for the 
 third option since you don't need to download often and people 
 just checking it out don't return frequently to check it out 
 again. Having an immediate search field, ideally with 
 autofocus, makes finding documentation a very easy task.



I'm slightly against autofocus on search field, as I am one of 
people who use Backspace to navigate to previous page and I'm 
always frustrated when I hit Backspace on Google search results 
page and it's not taking me to previous page.
But if majority thinks that autofocus on search is a good thing 
(I also think that not many people use Backspace as a means of 
navigation) than I would make it like that (and if there would be 
that little preferences page/popup this option is something that 
can go there together with justification settings).


 A prominent download button immediately visible on the home 
 page rather than the top nav-bar would be an improvement as 
 well. Practically every site with something to download does 
 this, for good reason. It's one of the first things that should 
 jump out at you when you view the site, making it as little 
 effort as possible to commit to at least downloading the 
 installer (see Dart, Python, Rust, Go, Ruby, etc). The longer / 
 more effort it takes to do something, the less likely people 
 are to try it unless they're already very convinced it's 
 something they need.


Download sites do that, so does sites that sell software. I think 
that dlang.org should focus on promoting D as a language, and 
compiler implementations should not be in spotlight.
Also I think that having Download in top-nav as a first option is 
prominent enough. I've put what I think are the most important 
sections in top-nav bar (other navigation items should go to 
context-sensitive sidebar).



 Apr 19 2014



 next sibling parent  "Rikki Cattermole" <alphaglosined gmail.com>  writes:


On Saturday, 19 April 2014 at 08:16:20 UTC, Aleksandar Ruzicic
wrote:
...

 Download sites do that, so does sites that sell software. I 
 think that dlang.org should focus on promoting D as a language, 
 and compiler implementations should not be in spotlight.
 Also I think that having Download in top-nav as a first option 
 is prominent enough. I've put what I think are the most 
 important sections in top-nav bar (other navigation items 
 should go to context-sensitive sidebar).


Also can we have things like a getting started guide? That really
impeded me at least when I was starting out.



 Apr 19 2014



prev sibling  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On 4/19/2014 4:16 AM, Aleksandar Ruzicic wrote:

 I'm slightly against autofocus on search field, as I am one of people
 who use Backspace to navigate to previous page and I'm always frustrated
 when I hit Backspace on Google search results page and it's not taking
 me to previous page.
 But if majority thinks that autofocus on search is a good thing (I also
 think that not many people use Backspace as a means of navigation) than
 I would make it like that (and if there would be that little preferences
 page/popup this option is something that can go there together with
 justification settings).


I use a browser extension to disable backspace navigation since I get 
annoyed when I try to type something and the browser decides to navigate 
to a different page ;).

That said, I don't really have an preference on autofocus vs not-autofocus.


 Download sites do that, so does sites that sell software. I think that
 dlang.org should focus on promoting D as a language, and compiler
 implementations should not be in spotlight.
 Also I think that having Download in top-nav as a first option is
 prominent enough. I've put what I think are the most important sections
 in top-nav bar (other navigation items should go to context-sensitive
 sidebar).


I strongly believe that a prominent link the the downloads page is one 
of the *most* important things to have in the top-nav bar. We may not be 
selling it for $$, but we are "selling" people on it. I know I get 
annoyed when I'm on some software's website, want to download it, and 
have to looking around for it because I don't see a download link in the 
typical download link location (top nav-bar). We want people to download 
it and try it, so it's good to match people's expectations here.



 Apr 19 2014



prev sibling  parent reply "Kagamin" <spam here.lot>  writes:


On Saturday, 19 April 2014 at 00:08:06 UTC, Kapps wrote:

 I do agree that the design of the current site is rather dated. 
 I rather like your new proposed design as well. One thing that 
 could be nicer is the search bar being a button to click. It's 
 standard now to just make it an input of type search with 
 place-holder text now, which is faster and more useable. Even 
 better, it could be automatically focused on when you load the 
 (documentation) page so you can immediately start typing to 
 look up an API / language feature.


Autofocus breaks site navigation: instead of returning to where 
you were previously, you end up focused on search box, which is 
really annoying. It also breaks page navigation (similar mistake: 
floating top panel on dart site). Whether it's standard or not, I 
don't know, because when I see such disgusting UX, I leave the 
site and never return if possible.
What you are talking about is what opensearch is for: you type 
request right in the browser without opening any site and get 
straight to the search results. I personally don't use search on 
the site and forcing it on me on every page transition would be 
undesirable.



 Apr 21 2014



  parent reply "Lars T. Kyllingstad" <public kyllingen.net>  writes:


On Monday, 21 April 2014 at 11:42:54 UTC, Kagamin wrote:

 Autofocus breaks site navigation: instead of returning to where 
 you were previously, you end up focused on search box, which is 
 really annoying. It also breaks page navigation (similar 
 mistake: floating top panel on dart site). Whether it's 
 standard or not, I don't know, because when I see such 
 disgusting UX, I leave the site and never return if possible.


I hate that too.  It also breaks in-page search with "/", which I 
use a lot.

In fact, I get seriously annoyed whenever a web site does 
*anything* to make my browser behave in an unexpected, 
non-standard way.  Like those sites that hijack the arrow keys 
for navigation between images or blog posts.  Or GitHub's 
keyboard shortcuts.  Grrrr...

When I want that stuff, I use a browser plug-in like Vimperator 
or Vimium.  I shouldn't have to install an add-on to *disable* it.



 Apr 21 2014



 next sibling parent  "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Monday, 21 April 2014 at 13:14:12 UTC, Lars T. Kyllingstad 
wrote:

 On Monday, 21 April 2014 at 11:42:54 UTC, Kagamin wrote:

 Autofocus breaks site navigation: instead of returning to 
 where you were previously, you end up focused on search box, 
 which is really annoying. It also breaks page navigation 
 (similar mistake: floating top panel on dart site). Whether 
 it's standard or not, I don't know, because when I see such 
 disgusting UX, I leave the site and never return if possible.


 I hate that too.  It also breaks in-page search with "/", which 
 I use a lot.

 In fact, I get seriously annoyed whenever a web site does 
 *anything* to make my browser behave in an unexpected, 
 non-standard way.  Like those sites that hijack the arrow keys 
 for navigation between images or blog posts.  Or GitHub's 
 keyboard shortcuts.  Grrrr...

 When I want that stuff, I use a browser plug-in like Vimperator 
 or Vimium.  I shouldn't have to install an add-on to *disable* 
 it.


Agreed. But given that I'll be implementing "preferences page" 
where you can choose your UX settings there can be autofocus 
on/off option too (which I would gladly disable by default).



 Apr 21 2014



prev sibling  parent  "Martin Nowak" <code dawg.eu>  writes:


Different strokes for different folks.
https://github.com/rejectedsoftware/ddox/pull/49



 Apr 25 2014



prev sibling next sibling parent reply "w0rp" <devw0rp gmail.com>  writes:


I like your design. Go forth and make it happen.

On line length, the optimal line length is somewhere between 70 
and 110 characters from what I have read. I found one study here 
which didn't turn up a great observable difference in reading 
speed or comprehension going from 80 to 110 characters.

http://www.perceptionweb.com/ecvp/ecvp03.pdf (Page 107)

This is a general theme from studies I have seen. Results seem to 
vary a bit. Something inside that range appears to be good.

I recommend Bootstrap for building sites, as it was worked well 
at my company. The designer here is a big fan of it, and when a 
site framework makes him happy, it's got to be pretty good.

As for avoiding the SCSS dependency, I'd say just go for plain 
CSS. SCSS and other CSS wrapper languages give you some nice 
features, like templates for cross-browser support or variables, 
but I don't think they justify the complexity involved in using 
them. We've been using SCSS at the company I currently work in, 
and so far all I've gotten out of SCSS is that it takes me longer 
to go through the feedback loop of making a change to a CSS file 
and seeing it happen in the browser, due to the milliseconds it 
takes to compile the CSS file. It's really not worth the trouble.

I'll say it again because it's important, go ahead and implement 
a new design right away. I look forward to it. Press on with 
something to avoid a design by committee scenario from emerging.



 Apr 22 2014



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Tuesday, 22 April 2014 at 12:21:57 UTC, w0rp wrote:

 and 110 characters from what I have read. I found one study 
 here which didn't turn up a great observable difference in 
 reading speed or comprehension going from 80 to 110 characters.


You can do all the quantitative laboratory experiments in the 
world, but at the end of the day the only thing that is certain 
is that people don't approach a web page as if they are 
participating in a reading contest, and that people are 
different, have different skills and motivation. So, being able 
to adapt the page to your own needs is the "right" thing to do.

What is certain is that testing with a heterogeneous group of 
real people is much more efficient than evaluation by a usability 
expert, no matter how proficient that expert is. ;-)



 Apr 22 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-04-22 14:21, w0rp wrote:

 I like your design. Go forth and make it happen.

 On line length, the optimal line length is somewhere between 70 and 110
 characters from what I have read. I found one study here which didn't
 turn up a great observable difference in reading speed or comprehension
 going from 80 to 110 characters.

 http://www.perceptionweb.com/ecvp/ecvp03.pdf (Page 107)

 This is a general theme from studies I have seen. Results seem to vary a
 bit. Something inside that range appears to be good.

 I recommend Bootstrap for building sites, as it was worked well at my
 company. The designer here is a big fan of it, and when a site framework
 makes him happy, it's got to be pretty good.

 As for avoiding the SCSS dependency, I'd say just go for plain CSS. SCSS
 and other CSS wrapper languages give you some nice features, like
 templates for cross-browser support or variables, but I don't think they
 justify the complexity involved in using them. We've been using SCSS at
 the company I currently work in, and so far all I've gotten out of SCSS
 is that it takes me longer to go through the feedback loop of making a
 change to a CSS file and seeing it happen in the browser, due to the
 milliseconds it takes to compile the CSS file. It's really not worth the
 trouble.


I say it's the opposite. I never use plain CSS or JavaScript these days. 
I mostly use Ruby on Rails where this is built-in and has good support. 
I'm using LiveReload together with Guard. When the Sass/CSS is updated 
it doesn't even need to reload the whole page, it just updates the 
stylesheet.

-- 
/Jacob Carlborg



 Apr 22 2014



prev sibling next sibling parent reply Martin Nowak <code dawg.eu>  writes:


 I have also tried to design something myself (although I'm not a
 designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks better
 (or at least more modern) than the current design.


This looks great, finally something that doesn't scare off people.
Please let me know if you need any help to make this happen.



 Apr 22 2014



  parent  "Aleksandar Ruzicic" <aleksandar ruzicic.info>  writes:


On Tuesday, 22 April 2014 at 22:24:25 UTC, Martin Nowak wrote:

 I have also tried to design something myself (although I'm not 
 a
 designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better
 (or at least more modern) than the current design.


 This looks great, finally something that doesn't scare off 
 people.
 Please let me know if you need any help to make this happen.


Thanks! I'll be pushing all my work to GitHub from day one (I'll 
create new branch at https://github.com/raleksandar/dlang.org) so 
anyone can fork and contribute, later this would be hopefuly 
merged with official dlang.org repo.



 Apr 22 2014



prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Thu, Apr 24, 2014 at 04:58:06AM -0400, Nick Sabalausky via Digitalmars-d
wrote:

 On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:


[...]

Usually when I run into a site with (1) microscopic fonts, (2) giant
(often multicolored) fonts, (3) no whitespace, or (4) has more
ads/filler than content, my fingers have an almost instinctual ctrl-W
(close tab) response. Sometimes not even one word registers in my
brain before I move on to the next site.


 
 Incidentally, ugly rainbow text is also why I set my mail client to
 plaintext-only ages ago.


[...]

I've never left terminal-only email clients. :P

For a short time at work I put up with webmail, because they didn't tell
me pop3 access was available. Boy, that was painful. Then one day I
discovered that I can use pop3, and oh the joy! I installed mutt and
fetchmail, and from that day on never looked back.

Nowadays, it seems that HTML-only mails are getting more common, which
is unfortunate. Luckily, there's `elinks -dump`, which one of these days
I'm gonna hook up to my .procmailrc so that I won't ever see HTML mails,
ever again. >:-)


On Thu, Apr 24, 2014 at 12:27:09PM +0000, via Digitalmars-d wrote:

 On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:

I agree. Unfortunately though, browsers haven't always has reasonable
defaults, so people had to work around, so now it's all pretty much
screwed.

Maybe what we need is a CSS for "sane-size-defaults: on;" which would
provide a "reboot" of the whole default font sizes.


 
 The defaults in the original browsers were set a bit large (16px), so
 Safari decided to set them smaller for a while. That sucked. Nowadays
 you can just set the scaling of the body to 87.5% of the default and
 get a reasonable size (14px).


Funny. I find anything below 16pt unreadably small. But then again, I
have a 1600x1200 screen. :P  Which I run ratpoison on, which means every
window is maximized. So my terminals use an 18pt font to get close to an
80-column display. :P



 What annoy me the most is non-promotional sites that set the body
 font-family to anything but the default sans-serif (which often
 happens to be pixel perfect, have good unicode support and is
 legible).


TBH, I find this "pixel perfect" obsession to be really silly.  It shows
that web developers don't understand that what the user sees is NOT what
developers see, because browsers come in many sizes and shapes, and
users' screens also come in many sizes and shapes. "This site is best
viewable in AAAxYYY resolution" is so last century. When are we gonna
grow out of that?!


On Thu, Apr 24, 2014 at 01:57:32PM +0000, Adam D. Ruppe via Digitalmars-d wrote:

 Another thing that kills me about the new "big picture up top,
 scroll to gigantic say-nothing text below" fad....
 
 The text below sounds like there might be some more learning to
 do. So I try to click on the headers.... nothing happens. No see
 more link.
 
 Apparently "Feature rich: we have more features than anybody!" is
 all they have to say. No explanation of what those features are.
 
 <a href="this-makes-me-angry-because-it-sux">Hatred.</a>


Yeah I noticed that about recent new sites. But then again, it's more
tolerable than the old "jampack every possible marketing slogan you can
onto a presumed 640x480 browser window until it's unreadably cluttered"
approach, which *still* conveyed basically no information.

"Feature-rich" has become one of those meaningless buzzwords that really
should be added to this page:

	http://www.dack.com/web/bullshit.html

:-P  Along with "innovative", "comprehensive", "powerful", "creative",
"cloud", "mature", etc., all of which have lost their meaning from
marketing overuse.


T

-- 
The diminished 7th chord is the most flexible and fear-instilling chord.
Use it often, use it unsparingly, to subdue your listeners into
submission!



 Apr 24 2014



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 24 April 2014 at 14:59:36 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Thu, Apr 24, 2014 at 04:58:06AM -0400, Nick Sabalausky via 
 Digitalmars-d wrote:

 On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:


 [...]

Usually when I run into a site with (1) microscopic fonts, 
(2) giant
(often multicolored) fonts, (3) no whitespace, or (4) has more
ads/filler than content, my fingers have an almost 
instinctual ctrl-W
(close tab) response. Sometimes not even one word registers 
in my
brain before I move on to the next site.


 
 Incidentally, ugly rainbow text is also why I set my mail 
 client to
 plaintext-only ages ago.


 [...]

 I've never left terminal-only email clients. :P

 For a short time at work I put up with webmail, because they 
 didn't tell
 me pop3 access was available. Boy, that was painful. Then one 
 day I
 discovered that I can use pop3, and oh the joy! I installed 
 mutt and
 fetchmail, and from that day on never looked back.

 Nowadays, it seems that HTML-only mails are getting more 
 common, which
 is unfortunate. Luckily, there's `elinks -dump`, which one of 
 these days
 I'm gonna hook up to my .procmailrc so that I won't ever see 
 HTML mails,
 ever again. >:-)


 On Thu, Apr 24, 2014 at 12:27:09PM +0000, via Digitalmars-d 
 wrote:

 On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky 
 wrote:

I agree. Unfortunately though, browsers haven't always has 
reasonable
defaults, so people had to work around, so now it's all 
pretty much
screwed.

Maybe what we need is a CSS for "sane-size-defaults: on;" 
which would
provide a "reboot" of the whole default font sizes.


 
 The defaults in the original browsers were set a bit large 
 (16px), so
 Safari decided to set them smaller for a while. That sucked. 
 Nowadays
 you can just set the scaling of the body to 87.5% of the 
 default and
 get a reasonable size (14px).


 Funny. I find anything below 16pt unreadably small.


According to the CCS 2.1 standard 1 px == 0.75pt.

http://www.w3.org/TR/CSS21/syndata.html#length-units

Thus:

16pt => 12px => 3.1mm at a reading distance of 71 cm.

Yep, that pretty tiny. :-)


 TBH, I find this "pixel perfect" obsession to be really silly.  
 It shows that web developers don't understand that what the user
 sees is NOT what developers see


If we are talking about fixed sizes, sure. Pixel perfect in this 
context means that black lines of the fonts are aligned with the 
pixel layout so you get sharp black lines and not blurry gray 
shit that looks like it are out of focus. To get that right you 
have to adjust the font/rendering engine so the lines match up.

When it comes to graphics there is no longer an excuse for not 
gong whole sale SVG. IE8 is thankfully not a contender anymore! 
:-) Misaligned vector-graphics is not so bad if you avoid 1 
hardware-pixel thin lines. (Or you can adjust it with javascript).

One property missing on LCDs that CRTs have is the lowpass filter 
after the D/A conversion, which leads to jagged artifacts. Thus 
they are "pixel perfect" by nature. There is now way around it. 
If you don't want "pixel perfect" then you have to go back to 
CRTs where the phosphors is your reconstruction filter. Of 
course, this doesn't matter with very high resolution displays.

(I am also clinging onto my 1600x1200 display…)


 "This site is best
 viewable in AAAxYYY resolution" is so last century. When are we 
 gonna grow out of that?!


I dunno.

The current fad is: «this site is best viewed on a cellphone so 
we have almost no content, but let's

                           SCALE UP THE
                            FONT AND
                         CENTER THE TEXT

so it looks nice on desktops. Mobile first!»



 Apr 24 2014



  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org>  writes:


Am 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>":

 According to the CCS 2.1 standard 1 px == 0.75pt.

 http://www.w3.org/TR/CSS21/syndata.html#length-units

 Thus:

 16pt => 12px => 3.1mm at a reading distance of 71 cm.


16pt => 21.3px



 Apr 24 2014



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 24 April 2014 at 15:55:36 UTC, Sönke Ludwig wrote:

 Am 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>":

 According to the CCS 2.1 standard 1 px == 0.75pt.

 http://www.w3.org/TR/CSS21/syndata.html#length-units

 Thus:

 16pt => 12px => 3.1mm at a reading distance of 71 cm.


 16pt => 21.3px


Yeah, I thought it was a bit odd, it sounded more like 9pt. I 
guess Theo should look into the DPI settings if possible.



 Apr 24 2014



  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Thu, Apr 24, 2014 at 03:59:17PM +0000, via Digitalmars-d wrote:

 On Thursday, 24 April 2014 at 15:55:36 UTC, Sönke Ludwig wrote:

Am 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dlang gmail.com>":

According to the CCS 2.1 standard 1 px == 0.75pt.

http://www.w3.org/TR/CSS21/syndata.html#length-units

Thus:

16pt => 12px => 3.1mm at a reading distance of 71 cm.


16pt => 21.3px


 
 Yeah, I thought it was a bit odd, it sounded more like 9pt. I guess Theo
 should look into the DPI settings if possible.


I like my fonts nice and big. It's just me. :)

I think I got confused and misread 12px as 12pt. 12px isn't unreadably
small on a lower resolution screen: at work, where the screen resolution
is 1280x1024, I have my fonts set to 15pt, which is about 12px. At home,
with a 1600x1200 screen, I have my font set to 18pt, not sure exactly
what that is in px, but should be around 17px I think.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs



 Apr 24 2014



prev sibling next sibling parent  "David Gileadi" <gileadis NSPMgmail.com>  writes:


Is this still happening? Is there a repo or a place I can go to 
help?



 May 06 2014



prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 Hello,

 I've been D enthusiast for couple of years now (but I do not 
 participate much in discussions here, although I read forums 
 almost daily), and I keep telling people about D and how 
 awesome it is.

 But, all this time D's official website somehow archaic look 
 kept troubling me. It reminds me of early 2000's design and I 
 really cannot associate this design with "modern" or "elegant", 
 what D really is.
 I think that we must invest time and energy improving the 
 website's look and feel as that is what people first coming to 
 D will see. We need to strive for "wow" and not "meh" as a 
 first impression.

 So I have started this thread to see if there is a chance for 
 complete redesign of dlang.org.

 I have also tried to design something myself (although I'm not 
 a designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?




 -- Aleksandar


Any updates? Any help needed pushing this forward?



 May 29 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


After watching Andrei's keynote where he was asking for help, and 
noticing that there wasn't any proof of someone working on this, 
I took charge.

http://w0rp.com:8010/

That's the design in the form of a single page website running on 
my Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I would like to keep going with this and just redesign the whole 
website. A few points worth noting.

* This is entirely a vibe.d website. (See the source.)
* For pages, DDoc is replaced with diet templates.
* I would still use ddox for generating library documentation.
* The page is mostly held together with Bootstrap, which is very 
good.
* The page is most of the way to being responsive (design sense), 
as it should be.
* The module in the middle is missing, I'd use some future 
version of Nowak's drepl and put a REPL right there on the front 
page.
* The logo is something I quickly put together with InkScape. 
Look at it as "please insert better logo here."

I encourage the use of diet over DDoc because it is simpler to 
insert dynamic content in the page, especially so for vibe.d. The 
support for doing conditional things or loops based on any 
dynamic content we can think of is right there in vibe.d.

Now unfortunately, I have two major complaints, for vibe.d and D 
itself.

For vibe.d, I can't think of a way to make changes to diet 
templates without recompiling the whole site. This doesn't seem 
so bad, given that compilation speed is very fast, but it builds 
up. This is because the process of experimenting with HTML 
becomes.

1. Make a change.
2. Recompile the whole program in a matter of seconds.
3. Refresh the browser window.

Those seconds in between making a change and seeing the results 
really build up over time. It's probably hard to describe without 
trying it yourself, but trust me, it matters. This is the kind of 
thing I have recently fought against at work, and it was well 
worth it. I replaced a Compass filesystem monitor with an even 
slightly broken libsass CPython compiler which compiled SCSS 
based on modification times. The couple seconds of difference has 
definitely improved the day-to-day life of myself and the web 
designer I work with.

This could be avoided if there was perhaps a way to rebuild diet 
templates at runtime. This could be enabled only for debug 
builds. So you could quickly make changes during development, and 
then compile everything statically for maximum speed for 
production.

The complaint I have for D is that too much memory is consumed 
for building D programs. The memory usage made it impossible for 
me to build the vibe.d site on my Linode, which the site above 
linked is running off of. The only way I was able to get the site 
to run on my Debian Wheezy server was to install a bunch of 
libraries from Debian testing, compile the program on my Arch 
Linux desktop, and then upload and run it on my server.

I'm not sure how to fix the issue myself, but something should be 
done to address this kind of issue. My Linode box has about 1GB 
of RAM with about 800MB free typically. Maybe I could have gotten 
things to build by increasing my swap space a little, I'm not 
sure.

So, what does everyone else think?



 May 31 2014



 next sibling parent reply "Dylan Knutson" <tcdknutson gmail.com>  writes:


Firstly, wow, the site looks beautiful. It has an air of 
professionality to it, but stays minimal and to the point. I 
think it'd be best if there was a code example above the fold 
though (e.g. how basically every programming language website 
does it nowadays), such as the word length snippet on the index 
of dlang.org as of now.

Maybe it'd be good to have something about CTFE/more on templates 
in the "Convenience" or "Power" section, as that has gotten much 
more useful in the language the past year or two. Also, I assume 
a good amount of work has to be done porting the rest of the site 
over (the community and documentation sections don't seem to be 
implemented).

Again, fantastic job :) it's great to see people taking 
initiative. Hopefully dlang.org can get a facelift in the near 
future. I'd be happy to spend some time working on porting more 
of the site if it gets a "green light" from upper management to 
be a replacement.



 May 31 2014



  parent  "w0rp" <devw0rp gmail.com>  writes:


On Saturday, 31 May 2014 at 20:01:50 UTC, Dylan Knutson wrote:

 Firstly, wow, the site looks beautiful. It has an air of 
 professionality to it, but stays minimal and to the point. I 
 think it'd be best if there was a code example above the fold 
 though (e.g. how basically every programming language website 
 does it nowadays), such as the word length snippet on the index 
 of dlang.org as of now.


Yeah, that's why I was mentioning something about hosting drepl 
on the site. One of the first things you see should be D code you 
can run from your browser.


 Maybe it'd be good to have something about CTFE/more on 
 templates in the "Convenience" or "Power" section, as that has 
 gotten much more useful in the language the past year or two. 
 Also, I assume a good amount of work has to be done porting the 
 rest of the site over (the community and documentation sections 
 don't seem to be implemented).


I just copied the text from the current website for now. I'm not 
a great copy writer myself. Someone else could surely do a better 
job of that.


 Again, fantastic job :) it's great to see people taking 
 initiative. Hopefully dlang.org can get a facelift in the near 
 future. I'd be happy to spend some time working on porting more 
 of the site if it gets a "green light" from upper management to 
 be a replacement.


Cool. I'll glady copy a bunch of pages into diet templates or 
whatever myself. I kind of need to do some of that anyway to make 
sure everything fits on the page as it should.



 May 31 2014



prev sibling next sibling parent reply "Meta" <jared771 gmail.com>  writes:


The flat design looks nice, but I really dislike the choice of 
background colour. It's bland and clashes quite badly with the 
white of the menu and content box.



 May 31 2014



  parent reply "Meta" <jared771 gmail.com>  writes:


On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:

 The flat design looks nice, but I really dislike the choice of 
 background colour. It's bland and clashes quite badly with the 
 white of the menu and content box.


For comparison, here's two images. One is the site with the 
background as the current gradient image, the second is the site 
with a background colour that matches your logo. Neither of them 
is particularly appealing, either, unfortunately.



 May 31 2014



  parent reply "Meta" <jared771 gmail.com>  writes:


On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:

 On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:

 The flat design looks nice, but I really dislike the choice of 
 background colour. It's bland and clashes quite badly with the 
 white of the menu and content box.


 For comparison, here's two images. One is the site with the 
 background as the current gradient image, the second is the 
 site with a background colour that matches your logo. Neither 
 of them is particularly appealing, either, unfortunately.


Whoops. http://imgur.com/oSHfFek,Mc81UYM



 May 31 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Saturday, 31 May 2014 at 20:38:41 UTC, Meta wrote:

 On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:

 On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:

 The flat design looks nice, but I really dislike the choice 
 of background colour. It's bland and clashes quite badly with 
 the white of the menu and content box.


 For comparison, here's two images. One is the site with the 
 background as the current gradient image, the second is the 
 site with a background colour that matches your logo. Neither 
 of them is particularly appealing, either, unfortunately.


 Whoops. http://imgur.com/oSHfFek,Mc81UYM


Yes, a darker background does look quite nice.



 May 31 2014



  parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 2014-05-31 at 20:40 +0000, w0rp via Digitalmars-d wrote:

 On Saturday, 31 May 2014 at 20:38:41 UTC, Meta wrote:

 On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:

 On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:

 The flat design looks nice, but I really dislike the choice 
 of background colour. It's bland and clashes quite badly with 
 the white of the menu and content box.


 For comparison, here's two images. One is the site with the 
 background as the current gradient image, the second is the 
 site with a background colour that matches your logo. Neither 
 of them is particularly appealing, either, unfortunately.


 Whoops. http://imgur.com/oSHfFek,Mc81UYM


 
 Yes, a darker background does look quite nice.


Contrast level is still a bit high though. The current dlang.org also
has this problem because of the use of white. I am not pushing dark grey
on light grey with spot colour (which is how Apple started out and still
use a lot) but something with less contrast might lead to a nice brand
imagery. Red, brown and black are clearly the base for a D brand, so
maybe washed out red-brown background rather than white. I haven't tried
this, it's just an idea – which may turn out to be rubbish.
 
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 May 31 2014



  parent reply Jacob Carlborg <doob me.com>  writes:


On 01/06/14 07:50, Russel Winder via Digitalmars-d wrote:


 Contrast level is still a bit high though. The current dlang.org also
 has this problem because of the use of white. I am not pushing dark grey
 on light grey with spot colour (which is how Apple started out and still
 use a lot) but something with less contrast might lead to a nice brand
 imagery. Red, brown and black are clearly the base for a D brand, so
 maybe washed out red-brown background rather than white. I haven't tried
 this, it's just an idea – which may turn out to be rubbish.


I tried and changed the background color of the #page-wrapper element to 
#CCCCCC. I think that looks good, although I usually prefer lighter themes.

-- 
/Jacob Carlborg



 Jun 02 2014



  parent  "w0rp" <devw0rp gmail.com>  writes:


On Monday, 2 June 2014 at 12:42:02 UTC, Jacob Carlborg wrote:

 On 01/06/14 07:50, Russel Winder via Digitalmars-d wrote:


 Contrast level is still a bit high though. The current 
 dlang.org also
 has this problem because of the use of white. I am not pushing 
 dark grey
 on light grey with spot colour (which is how Apple started out 
 and still
 use a lot) but something with less contrast might lead to a 
 nice brand
 imagery. Red, brown and black are clearly the base for a D 
 brand, so
 maybe washed out red-brown background rather than white. I 
 haven't tried
 this, it's just an idea – which may turn out to be rubbish.


 I tried and changed the background color of the #page-wrapper 
 element to #CCCCCC. I think that looks good, although I usually 
 prefer lighter themes.


By the way, feel free to contribute to development of the new 
site if you want to, and this goes for everyone who's interested 
in helping out. https://github.com/w0rp/new-dlang.org

I'm currently in the process of breaking down the change log into 
smaller pages, as the change log was getting near to 1MB of HTML. 
At this point, working on anything but the change log page could 
be helpful.



 Jun 02 2014



prev sibling next sibling parent reply "Kapps" <opantm2+spam gmail.com>  writes:


On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:

 After watching Andrei's keynote where he was asking for help, 
 and noticing that there wasn't any proof of someone working on 
 this, I took charge.

 http://w0rp.com:8010/

 That's the design in the form of a single page website running 
 on my Linode. The source is available here.

 https://github.com/w0rp/new-dlang.org


I definitely like it. It scales fairly nicely, and works on high 
DPI screens very nicely thanks to the lack of non-svg images 
(excluding the Twitter bar which is somewhat lower quality 
because it uses low-res pngs for avatars). If the logo gets 
replaced, I'd like to see it remain SVG.

One thing that's a bit broken is that "Modern convenience. 
Modelling power. Native efficiency." wraps to put "efficiency." 
on a different line. Perhaps the text should be made smaller 
there. Another thing that I'd like to see is a much more 
prominent download button. It's definitely easier to find with 
this redesign, but a prominent download button is one of the most 
important things when you're trying to get someone to try 
something, right after a useful code sample (ideally with the 
mentioned REPL).



 May 31 2014



 next sibling parent  "w0rp" <devw0rp gmail.com>  writes:


On Saturday, 31 May 2014 at 20:52:56 UTC, Kapps wrote:

 One thing that's a bit broken is that "Modern convenience. 
 Modelling power. Native efficiency." wraps to put "efficiency." 
 on a different line. Perhaps the text should be made smaller 
 there. Another thing that I'd like to see is a much more 
 prominent download button. It's definitely easier to find with 
 this redesign, but a prominent download button is one of the 
 most important things when you're trying to get someone to try 
 something, right after a useful code sample (ideally with the 
 mentioned REPL).


Yes, that line should be smaller. Maybe the download link at the 
top could be another colour. Maybe next to the REPL it can say, 
"Download now!"



 May 31 2014



prev sibling  parent  FG <home fgda.pl>  writes:


On 2014-05-31 22:52, Kapps wrote:

 One thing that's a bit broken is that "Modern convenience. Modelling power.
Native efficiency." wraps to put "efficiency." on a different line. Perhaps the
text should be made smaller there.


Or just put nbsp between Native and efficiency.

As for page background -- yes, it might be a bit too close to the color of the
article, especially since there are no borders around it. Works fine here but
in worse lighting conditions and on poor displays the contrast should be
higher, say, #c0c0c0 instead of the current #d7d6d6.



 Jun 01 2014



prev sibling next sibling parent  "deadalnix" <deadalnix gmail.com>  writes:


On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:

 After watching Andrei's keynote where he was asking for help, 
 and noticing that there wasn't any proof of someone working on 
 this, I took charge.

 http://w0rp.com:8010/

 That's the design in the form of a single page website running 
 on my Linode. The source is available here.

 https://github.com/w0rp/new-dlang.org

 I would like to keep going with this and just redesign the 
 whole website. A few points worth noting.

 * This is entirely a vibe.d website. (See the source.)
 * For pages, DDoc is replaced with diet templates.
 * I would still use ddox for generating library documentation.
 * The page is mostly held together with Bootstrap, which is 
 very good.
 * The page is most of the way to being responsive (design 
 sense), as it should be.
 * The module in the middle is missing, I'd use some future 
 version of Nowak's drepl and put a REPL right there on the 
 front page.
 * The logo is something I quickly put together with InkScape. 
 Look at it as "please insert better logo here."

 I encourage the use of diet over DDoc because it is simpler to 
 insert dynamic content in the page, especially so for vibe.d. 
 The support for doing conditional things or loops based on any 
 dynamic content we can think of is right there in vibe.d.

 Now unfortunately, I have two major complaints, for vibe.d and 
 D itself.

 For vibe.d, I can't think of a way to make changes to diet 
 templates without recompiling the whole site. This doesn't seem 
 so bad, given that compilation speed is very fast, but it 
 builds up. This is because the process of experimenting with 
 HTML becomes.

 1. Make a change.
 2. Recompile the whole program in a matter of seconds.
 3. Refresh the browser window.

 Those seconds in between making a change and seeing the results 
 really build up over time. It's probably hard to describe 
 without trying it yourself, but trust me, it matters. This is 
 the kind of thing I have recently fought against at work, and 
 it was well worth it. I replaced a Compass filesystem monitor 
 with an even slightly broken libsass CPython compiler which 
 compiled SCSS based on modification times. The couple seconds 
 of difference has definitely improved the day-to-day life of 
 myself and the web designer I work with.

 This could be avoided if there was perhaps a way to rebuild 
 diet templates at runtime. This could be enabled only for debug 
 builds. So you could quickly make changes during development, 
 and then compile everything statically for maximum speed for 
 production.

 The complaint I have for D is that too much memory is consumed 
 for building D programs. The memory usage made it impossible 
 for me to build the vibe.d site on my Linode, which the site 
 above linked is running off of. The only way I was able to get 
 the site to run on my Debian Wheezy server was to install a 
 bunch of libraries from Debian testing, compile the program on 
 my Arch Linux desktop, and then upload and run it on my server.

 I'm not sure how to fix the issue myself, but something should 
 be done to address this kind of issue. My Linode box has about 
 1GB of RAM with about 800MB free typically. Maybe I could have 
 gotten things to build by increasing my swap space a little, 
 I'm not sure.

 So, what does everyone else think?


I love you. Will you marry me ?



 May 31 2014



prev sibling next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com>  writes:


On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:

 After watching Andrei's keynote where he was asking for help, 
 and noticing that there wasn't any proof of someone working on 
 this, I took charge.

 http://w0rp.com:8010/

 That's the design in the form of a single page website running 
 on my Linode. The source is available here.

 https://github.com/w0rp/new-dlang.org

 I would like to keep going with this and just redesign the 
 whole website. A few points worth noting.

 * This is entirely a vibe.d website. (See the source.)
 * For pages, DDoc is replaced with diet templates.
 * I would still use ddox for generating library documentation.
 * The page is mostly held together with Bootstrap, which is 
 very good.
 * The page is most of the way to being responsive (design 
 sense), as it should be.
 * The module in the middle is missing, I'd use some future 
 version of Nowak's drepl and put a REPL right there on the 
 front page.
 * The logo is something I quickly put together with InkScape. 
 Look at it as "please insert better logo here."

 I encourage the use of diet over DDoc because it is simpler to 
 insert dynamic content in the page, especially so for vibe.d. 
 The support for doing conditional things or loops based on any 
 dynamic content we can think of is right there in vibe.d.

 Now unfortunately, I have two major complaints, for vibe.d and 
 D itself.

 For vibe.d, I can't think of a way to make changes to diet 
 templates without recompiling the whole site. This doesn't seem 
 so bad, given that compilation speed is very fast, but it 
 builds up. This is because the process of experimenting with 
 HTML becomes.

 1. Make a change.
 2. Recompile the whole program in a matter of seconds.
 3. Refresh the browser window.

 Those seconds in between making a change and seeing the results 
 really build up over time. It's probably hard to describe 
 without trying it yourself, but trust me, it matters. This is 
 the kind of thing I have recently fought against at work, and 
 it was well worth it. I replaced a Compass filesystem monitor 
 with an even slightly broken libsass CPython compiler which 
 compiled SCSS based on modification times. The couple seconds 
 of difference has definitely improved the day-to-day life of 
 myself and the web designer I work with.

 This could be avoided if there was perhaps a way to rebuild 
 diet templates at runtime. This could be enabled only for debug 
 builds. So you could quickly make changes during development, 
 and then compile everything statically for maximum speed for 
 production.

 The complaint I have for D is that too much memory is consumed 
 for building D programs. The memory usage made it impossible 
 for me to build the vibe.d site on my Linode, which the site 
 above linked is running off of. The only way I was able to get 
 the site to run on my Debian Wheezy server was to install a 
 bunch of libraries from Debian testing, compile the program on 
 my Arch Linux desktop, and then upload and run it on my server.

 I'm not sure how to fix the issue myself, but something should 
 be done to address this kind of issue. My Linode box has about 
 1GB of RAM with about 800MB free typically. Maybe I could have 
 gotten things to build by increasing my swap space a little, 
 I'm not sure.

 So, what does everyone else think?


Looks better than what we have now.

Doesn't look as good/to the point/'new' as e.g. 
http://www.rust-lang.org/
or https://www.dartlang.org/ , I suspect the main problem is 
content of the
front page (wall of text, 'too much stuff' instead of simple 
short points), not as much design. I'd also suggest experimenting 
with a less "regular" layout.



 May 31 2014



  parent  "w0rp" <devw0rp gmail.com>  writes:


On Saturday, 31 May 2014 at 22:54:28 UTC, Kiith-Sa wrote:

 Looks better than what we have now.

 Doesn't look as good/to the point/'new' as e.g. 
 http://www.rust-lang.org/
 or https://www.dartlang.org/ , I suspect the main problem is 
 content of the
 front page (wall of text, 'too much stuff' instead of simple 
 short points), not as much design. I'd also suggest 
 experimenting with a less "regular" layout.


I think the trick is to have very brief 'above the fold' content. 
This trick is used by a lot of news publications and several 
websites. I think if we put a tagline and just a couple of points 
at the top of the page, then put details below the fold, it would 
look cleaner. I think Dart presents itself a lot better in that 
manner. When you are at the top you see just a little bit of 
information. As you scroll down a tour of the language is 
revealed to you.



 May 31 2014



prev sibling next sibling parent reply Rikki Cattermole <alphaglosined gmail.com>  writes:


On 1/06/2014 7:49 a.m., w0rp wrote:

 After watching Andrei's keynote where he was asking for help, and
 noticing that there wasn't any proof of someone working on this, I took
 charge.

 http://w0rp.com:8010/

 That's the design in the form of a single page website running on my
 Linode. The source is available here.

 https://github.com/w0rp/new-dlang.org

 I would like to keep going with this and just redesign the whole
 website. A few points worth noting.

 * This is entirely a vibe.d website. (See the source.)
 * For pages, DDoc is replaced with diet templates.
 * I would still use ddox for generating library documentation.
 * The page is mostly held together with Bootstrap, which is very good.
 * The page is most of the way to being responsive (design sense), as it
 should be.
 * The module in the middle is missing, I'd use some future version of
 Nowak's drepl and put a REPL right there on the front page.
 * The logo is something I quickly put together with InkScape. Look at it
 as "please insert better logo here."

 I encourage the use of diet over DDoc because it is simpler to insert
 dynamic content in the page, especially so for vibe.d. The support for
 doing conditional things or loops based on any dynamic content we can
 think of is right there in vibe.d.


+1


 Now unfortunately, I have two major complaints, for vibe.d and D itself.

 For vibe.d, I can't think of a way to make changes to diet templates
 without recompiling the whole site. This doesn't seem so bad, given that
 compilation speed is very fast, but it builds up. This is because the
 process of experimenting with HTML becomes.

 1. Make a change.
 2. Recompile the whole program in a matter of seconds.
 3. Refresh the browser window.

 Those seconds in between making a change and seeing the results really
 build up over time. It's probably hard to describe without trying it
 yourself, but trust me, it matters. This is the kind of thing I have
 recently fought against at work, and it was well worth it. I replaced a
 Compass filesystem monitor with an even slightly broken libsass CPython
 compiler which compiled SCSS based on modification times. The couple
 seconds of difference has definitely improved the day-to-day life of
 myself and the web designer I work with.

 This could be avoided if there was perhaps a way to rebuild diet
 templates at runtime. This could be enabled only for debug builds. So
 you could quickly make changes during development, and then compile
 everything statically for maximum speed for production.


The problem with diet is it compiles directly to D code, hence forth its 
not really possible at the moment.
However as I believe Sonke has said previous it is out of scope of Vibe. 
Its actually in the scope of Cmsed instead.

I have looked into doing just this, reloading of templates. And from 
what I can ascertain reliably we need shared library support. While this 
is doable upon Linux, it isn't on Windows. Until its available on 
Windows I will not use it.

My thread on the dub forum is here[0].
Basically I am also blocked by dub, to be able to grab all the previous 
templates ext. From libraries and push them into a findable place at 
runtime.


 The complaint I have for D is that too much memory is consumed for
 building D programs. The memory usage made it impossible for me to build
 the vibe.d site on my Linode, which the site above linked is running off
 of. The only way I was able to get the site to run on my Debian Wheezy
 server was to install a bunch of libraries from Debian testing, compile
 the program on my Arch Linux desktop, and then upload and run it on my
 server.


I personally allow for atleast 1.5 to 2gb of ram to build anything with 
D. Cmsed base package alone takes around 700mb. And thats with a LOT of 
CTFE work going on. I can only see that increasing.
So I'd like a way for dmd to utilize memory better even if it means 
slowing down for larger builds. For small builds the current way is 
great, just for larger we need alternative means.


 I'm not sure how to fix the issue myself, but something should be done
 to address this kind of issue. My Linode box has about 1GB of RAM with
 about 800MB free typically. Maybe I could have gotten things to build by
 increasing my swap space a little, I'm not sure.

 So, what does everyone else think?


Definitely looks nicer. But I must say it does feel a little clunky in 
some places (although don't ask how to fix, I don't know how to myself).

[0] 
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1404/



 May 31 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 1 June 2014 at 03:26:30 UTC, Rikki Cattermole wrote:

 The problem with diet is it compiles directly to D code, hence 
 forth its not really possible at the moment.
 However as I believe Sonke has said previous it is out of scope 
 of Vibe. Its actually in the scope of Cmsed instead.

 I have looked into doing just this, reloading of templates. And 
 from what I can ascertain reliably we need shared library 
 support. While this is doable upon Linux, it isn't on Windows. 
 Until its available on Windows I will not use it.

 My thread on the dub forum is here[0].
 Basically I am also blocked by dub, to be able to grab all the 
 previous templates ext. From libraries and push them into a 
 findable place at runtime.


I would also consider using a different template engine entirely, 
one which is less powerful but which can be automatically 
recompiled at runtime. I would consider something with diet 
syntax, but where only some of the D language parts actually 
work. (The '-' syntax parts.)


 I personally allow for atleast 1.5 to 2gb of ram to build 
 anything with D. Cmsed base package alone takes around 700mb. 
 And thats with a LOT of CTFE work going on. I can only see that 
 increasing.
 So I'd like a way for dmd to utilize memory better even if it 
 means slowing down for larger builds. For small builds the 
 current way is great, just for larger we need alternative means.


I was thinking about this, and it might be good to offer a switch 
for lower memory build profiles. As far as I recall, I believe 
the memory usage comes from the philosophy that you can malloc, 
malloc, malloc, then exit the process for speed. I think it was 
freeing some memory and so on which would reduce build speed. I 
might be talking nonsense, but it would be nice to have an option 
to reduce build speed and also reduce memory usage. Of course, 
having the best of both worlds is always great.



 Jun 01 2014



  parent  =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 01.06.2014 11:54, schrieb w0rp:

 On Sunday, 1 June 2014 at 03:26:30 UTC, Rikki Cattermole wrote:

 The problem with diet is it compiles directly to D code, hence forth
 its not really possible at the moment.
 However as I believe Sonke has said previous it is out of scope of
 Vibe. Its actually in the scope of Cmsed instead.

 I have looked into doing just this, reloading of templates. And from
 what I can ascertain reliably we need shared library support. While
 this is doable upon Linux, it isn't on Windows. Until its available on
 Windows I will not use it.

 My thread on the dub forum is here[0].
 Basically I am also blocked by dub, to be able to grab all the
 previous templates ext. From libraries and push them into a findable
 place at runtime.


 I would also consider using a different template engine entirely, one
 which is less powerful but which can be automatically recompiled at
 runtime. I would consider something with diet syntax, but where only
 some of the D language parts actually work. (The '-' syntax parts.)


I thought there was a ticket open to let Diet templates automatically 
recompile in the background for development, but didn't find one - newly 
opened ticket: [1]. I definitely consider that particular feature within 
the scope of vibe.d (in contrast to dynamic loading of high level 
components), but I'm currently lacking the time to implement it myself.

For the big text content pages, it may make sense to stay with DDOC and 
use the DDOC processor of DDOX [2]. Another possibility would be to use 
enhanced Markdown. Unfortunately the Markdown compiler in vibe.d doesn't 
currently support tables, though (although those can of course be 
inserted using inline HTML).


[1]: https://github.com/rejectedsoftware/vibe.d/issues/676
[2]: https://github.com/rejectedsoftware/ddox/blob/master/source/ddox/ddoc.d



 Jun 01 2014



prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Sat, 2014-05-31 at 19:49 +0000, w0rp via Digitalmars-d wrote:

 After watching Andrei's keynote where he was asking for help, and 
 noticing that there wasn't any proof of someone working on this, 
 I took charge.
 
 http://w0rp.com:8010/


I have to admit my initial reaction on seeing this was: oh no not
another bland "me too" Angular/Ember/Drupal style three-column,
client-side, flat menu system more or less like every other new site
created because that is the fashionable style of the moment. On the
other hand others like it so, go with it.

For me the issue is branding. Whatever it's faults, the current
dlang.org does have a unique style to it.

I think having humour on the site is a good thing, cf. the D figure on
dlang.org. It would be good to do more with the D figure, or some other
mascot. Java has Duke, Go has the gopher, there is a lot of mileage in
having such a character, not only for the website, but also for
presentations. Having a mascot that can be used for humour helps
massively. When Sun controlled Duke it was all a bit tedious, once the
mascot was released, many people created many variants leading to an
extremely useful tool for enlivening presentations.


 That's the design in the form of a single page website running on 
 my Linode. The source is available here.
 
 https://github.com/w0rp/new-dlang.org
 
 I would like to keep going with this and just redesign the whole 
 website. A few points worth noting.
 
 * This is entirely a vibe.d website. (See the source.)


Seems entirely reasonable in the context :-) In fact it would be worth
ensuring this fact is front and centre so that anyone alighting on the
site knows it is vibe.d, i.e. D, powered.


 * For pages, DDoc is replaced with diet templates.
 * I would still use ddox for generating library documentation.
 * The page is mostly held together with Bootstrap, which is very 
 good.
 * The page is most of the way to being responsive (design sense), 
 as it should be.
 * The module in the middle is missing, I'd use some future 
 version of Nowak's drepl and put a REPL right there on the front 
 page.


Go has the Go playground rather than trying to create a REPL per se (cf.
http://golang.org/). Despite the fashion for REPLs, I find them
irritating. I am much more in favour of a tiny lightweight edit and a
fast compile/execution of the editor content. Another example of this is
IPython notebooks. Python and IPython have REPLs, which have their uses,
but the IPython notebooks are modern literate programming. Well actually
their main use is for writing documents (especially scientific papers to
be shipped) that include executable code. It is an idea that has totally
won over many in bioinformatics, HPC, and data sciences in general. It
wouldn't surprise me if Go could do something similar in the near
future. 


 * The logo is something I quickly put together with InkScape. 
 Look at it as "please insert better logo here."


Just use the logo from dlang.org? It is effectively, and possibly
actually, the official logo.


 I encourage the use of diet over DDoc because it is simpler to 
 insert dynamic content in the page, especially so for vibe.d. The 
 support for doing conditional things or loops based on any 
 dynamic content we can think of is right there in vibe.d.
 
 Now unfortunately, I have two major complaints, for vibe.d and D 
 itself.
 
 For vibe.d, I can't think of a way to make changes to diet 
 templates without recompiling the whole site. This doesn't seem 
 so bad, given that compilation speed is very fast, but it builds 
 up. This is because the process of experimenting with HTML 
 becomes.


Not so bad for releases, but terrible for development.

Grails and Django go to great lengths to ensure that the development
environment is entirely local to the development machine and has
dynamic, and fast, update of all content. So as soon as you write back a
file to the filestore the development server gets notified and reloads
the site as needed. This makes for very fast evolution of things — but I
am probably "teaching grandmother to such eggs" here.


 1. Make a change.
 2. Recompile the whole program in a matter of seconds.
 3. Refresh the browser window.
 
 Those seconds in between making a change and seeing the results 
 really build up over time. It's probably hard to describe without 
 trying it yourself, but trust me, it matters. This is the kind of 
 thing I have recently fought against at work, and it was well 
 worth it. I replaced a Compass filesystem monitor with an even 
 slightly broken libsass CPython compiler which compiled SCSS 
 based on modification times. The couple seconds of difference has 
 definitely improved the day-to-day life of myself and the web 
 designer I work with.


I can attest to the pain of a system that takes 5s or 6s to refresh, it
becomes horribly painful. To the extent of giving up and switching
infrastructure.


 This could be avoided if there was perhaps a way to rebuild diet 
 templates at runtime. This could be enabled only for debug 
 builds. So you could quickly make changes during development, and 
 then compile everything statically for maximum speed for 
 production.
 
 The complaint I have for D is that too much memory is consumed 
 for building D programs. The memory usage made it impossible for 
 me to build the vibe.d site on my Linode, which the site above 
 linked is running off of. The only way I was able to get the site 
 to run on my Debian Wheezy server was to install a bunch of 
 libraries from Debian testing, compile the program on my Arch 
 Linux desktop, and then upload and run it on my server.


Isn't the problem here that you are having to deploy in order to
develop? Maybe I am just missing something, but it sounds as though
there isn't actually a development workflow, just a create and release
one.


 I'm not sure how to fix the issue myself, but something should be 
 done to address this kind of issue. My Linode box has about 1GB 
 of RAM with about 800MB free typically. Maybe I could have gotten 
 things to build by increasing my swap space a little, I'm not 
 sure.
 
 So, what does everyone else think?


The Go website has it's faults, but it has a lot of good stuff,
analogues of which would be well worth considering for a revised
dlang.org. dlang.org may be a bit static and not of the currently
fashionable style, but it has a brand image.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 May 31 2014



 next sibling parent  "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 1 June 2014 at 05:46:57 UTC, Russel Winder via 
Digitalmars-d wrote:

 The complaint I have for D is that too much memory is consumed 
 for building D programs. The memory usage made it impossible 
 for me to build the vibe.d site on my Linode, which the site 
 above linked is running off of. The only way I was able to get 
 the site to run on my Debian Wheezy server was to install a 
 bunch of libraries from Debian testing, compile the program on 
 my Arch Linux desktop, and then upload and run it on my server.


 Isn't the problem here that you are having to deploy in order to
 develop? Maybe I am just missing something, but it sounds as 
 though
 there isn't actually a development workflow, just a create and 
 release
 one.


Yes, that is a deployment issue. Deployment is a hot issue for 
me, for some reason. I tend to get annoyed if building software 
or deploying it is just a bit too tricky to do. So when they 
work, I like things like 'git pull origin master && dub build.'


 The Go website has it's faults, but it has a lot of good stuff,
 analogues of which would be well worth considering for a revised
 dlang.org. dlang.org may be a bit static and not of the 
 currently
 fashionable style, but it has a brand image.


Branding does need to be worked on. Speaking of the site I'm 
working on... I would love to see something like the current D 
logo, but flatter. Then I think it needs a bit more colour in a 
few places. (We've adopted 'sort of blackish' and 'sort of 
redish' as brand colours. I also like D guy. I'd like to see a D 
guy which just fits naturally on the pages. It's kind of hard to 
tell what would unless you just put an image on the page and see 
what fits.



 Jun 01 2014



prev sibling  parent reply FG <home fgda.pl>  writes:


On 2014-06-01 07:46, Russel Winder via Digitalmars-d wrote:

 I think having humour on the site is a good thing, cf. the D figure on
 dlang.org. It would be good to do more with the D figure, or some other
 mascot. Java has Duke, Go has the gopher [...]


Please, no. Whatever you do, don't create something this hideous. :)
http://blog.golang.org/gopher



 Jun 01 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


I just updated the site. Here are the main changes.

* The background is now dark. I tried a linear-gradient for a 
little bit, but it made scrolling down the page much, much 
slower. I shall try out drawing a gradient in GIMP instead.
* The column on the right gets fixed when you scroll down, but 
the Bootstrap tool for this has a bug when you scroll all the way 
to the bottom some times which I need to get fixed.
* I added a download page I wrote a bit of text for.

Check out the download page here.

http://w0rp.com:8010/download

The old URL (download.html) is set up with a redirect. 
(Redirecting like this is vital for SEO.)

I want to fix that scrolling bug, account for resizing a window 
smaller than the length of the right column (I've seen this issue 
come up time and time again in browsers), Give the download 
button on the top a bit more colour, and get a nice gradient in 
which doesn't slow the page down. It was looking pretty good, but 
I absolutely will not use linear-gradient on the page after I saw 
how it ruined smooth scrolling.

Also, the table of contents there is currently a manual job, but 
I reckon there are clever things I can do with diet to generate 
it. Something like this...

- import dlang.toc;

append content
     ...

     - heading(h2, "Title");

...

append extra-sidebar
     - toc();

I bet I can make this syntax possible.

Out for now.



 Jun 01 2014



 next sibling parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Sunday, 1 June 2014 at 13:29:38 UTC, w0rp wrote:

 I just updated the site. Here are the main changes.

 <snip>


Had to force a refresh to see the changes. I can't decide if I
like the dark background better or worse. Either looks fine
though.



 Jun 01 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 1 June 2014 at 18:42:51 UTC, Brad Anderson wrote:

 On Sunday, 1 June 2014 at 13:29:38 UTC, w0rp wrote:

 I just updated the site. Here are the main changes.

 <snip>


 Had to force a refresh to see the changes. I can't decide if I
 like the dark background better or worse. Either looks fine
 though.


You just reminded me to put in a query string version hack at 
some point. I typically use something like 
?v=<epoch_of_server_start> or similar.



 Jun 01 2014



 next sibling parent  "w0rp" <devw0rp gmail.com>  writes:


https://github.com/w0rp/new-dlang.org/blob/master/src/dlang/toc.d

I just implemented my Table of Contents idea for use in the diet 
templates.

// Write a heading and add it to the table of contents in one go.
|!= h2(toc, "anchor", "Title")

// Write the table of contents out as html.
|!= toc.write("Title")

There are functions named 'h1' to 'h6' to use, and it works. Now 
it should be dead simple to write headings and generate a table 
of contents for a number of pages.



 Jun 01 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 01/06/14 21:56, w0rp wrote:


 You just reminded me to put in a query string version hack at some
 point. I typically use something like ?v=<epoch_of_server_start> or
 similar.


That's not reliable. It's usually assets that are the problem, CSS, JS, 
images and so on. They should have a unique hash based on the content 
appended to the filename. Then you can have really long cache timeout 
(or what it's called) on those files.

-- 
/Jacob Carlborg



 Jun 02 2014



prev sibling next sibling parent  "Rusty D. Shackleford" <nanr9d gmail.com>  writes:


On Sunday, 1 June 2014 at 13:29:38 UTC, w0rp wrote:

 I just updated the site. Here are the main changes.

 * The background is now dark. I tried a linear-gradient for a 
 little bit, but it made scrolling down the page much, much 
 slower. I shall try out drawing a gradient in GIMP instead.
 * The column on the right gets fixed when you scroll down, but 
 the Bootstrap tool for this has a bug when you scroll all the 
 way to the bottom some times which I need to get fixed.
 * I added a download page I wrote a bit of text for.

 Check out the download page here.

 http://w0rp.com:8010/download


I find the dark background pretty hard on the eyes in contrast
with the light foreground, maybe it's just me but I preferred the
light one.



 Jun 01 2014



prev sibling  parent reply "Kagamin" <spam here.lot>  writes:


Hmm... doesn't scale well, the main text remains crammed into 
fixed 1/3 of the page width, the rest is empty space.



 Jun 02 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Monday, 2 June 2014 at 19:16:04 UTC, Kagamin wrote:

 Hmm... doesn't scale well, the main text remains crammed into 
 fixed 1/3 of the page width, the rest is empty space.


There should be a maximum width on the text you read on a page. 
Once column size becomes so large, your reading speed will 
decrease.



 Jun 03 2014



  parent reply "Kagamin" <spam here.lot>  writes:


Shouldn't it be measured in characters instead of percentage of 
page width?



 Jun 03 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


I have updated the site and the repository with all of the D 
changelogs split into their own pages. I had to reformat a few 
things, primarily example code, so it would fit nicely in smaller 
column sizes. I marked sections with headings so it fits into a 
table of contents. One major thing that's missing is syntax 
highlighting, as I'm not sure what to use for that.

http://w0rp.com:8010/changelog

Here is what I've noticed so far that's good about the diet 
templates.

1. The template syntax, taken from Jade, is easy to understand 
and clean.
2. I can do tricks like the table of contents easily.

However, with the good comes the bad.

1. If you are recompiling one template, you are recompiling *all* 
of them. I'm getting closer to 100 templates, and it takes 
seconds to compile.
2. Compiling many templates allocates like crazy during compile 
time and eats memory like a hog. It takes *5GB* of RAM to compile 
all of these templates.

It seems like the vibe.d diet templates take heap allocation 
during compilation time way, way too far, to the point of them 
being impractical to use for large websites. Somewhere around 100 
templates is something I would expect for a reasonably sized 
website.

So I have a plea or two for vibe.d

In addition to recompiling diet templates automatically during 
development, which has been mentioned before, I believe there 
should be an option to defer compilation of a template the first 
time, during development, until you view a page using it for the 
first time. This woud solve the slower compilation issue, because 
then you'd only pay for what you used.

Second, something must be done about memory allocation during 
compilation of diet templates. There's too much going on there.

That's it for now.



 Jun 09 2014



  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 10.06.2014 02:18, schrieb w0rp:

 I have updated the site and the repository with all of the D changelogs
 split into their own pages. I had to reformat a few things, primarily
 example code, so it would fit nicely in smaller column sizes. I marked
 sections with headings so it fits into a table of contents. One major
 thing that's missing is syntax highlighting, as I'm not sure what to use
 for that.

 http://w0rp.com:8010/changelog

 Here is what I've noticed so far that's good about the diet templates.

 1. The template syntax, taken from Jade, is easy to understand and clean.
 2. I can do tricks like the table of contents easily.

 However, with the good comes the bad.

 1. If you are recompiling one template, you are recompiling *all* of
 them. I'm getting closer to 100 templates, and it takes seconds to compile.


Sounds kind of like an ironic joke when viewed from a C++ background ;)

But yes, it's definitely not what you want to have for D. I'm not sure 
how much can be done about that, though - except from rewriting the CTFE 
engine with performance in mind (maybe even using a JIT compiler). Or 
maybe it's possible to be more liberal with algorithmic optimizations 
when the CTFE memory usage brought to a reasonable level.


 2. Compiling many templates allocates like crazy during compile time and
 eats memory like a hog. It takes *5GB* of RAM to compile all of these
 templates.


Yes, which is why (at least with the current compiler front end) I'd 
strongly recommend to put long text content in a different format that 
is inserted at runtime (e.g. DDOC or Markdown).


 It seems like the vibe.d diet templates take heap allocation during
 compilation time way, way too far, to the point of them being
 impractical to use for large websites. Somewhere around 100 templates is
 something I would expect for a reasonably sized website.


It's not heap allocations. The problem is that during CTFE, currently 
basically every variable change allocates memory that is never freed 
again. I've used a few tricks to get the memory usage down (which is why 
the Diet compiler source code doesn't look very pretty), but basically 
the only way to get reasonable memory use is to fix the D front end.


 So I have a plea or two for vibe.d

 In addition to recompiling diet templates automatically during
 development, which has been mentioned before, I believe there should be
 an option to defer compilation of a template the first time, during
 development, until you view a page using it for the first time. This
 woud solve the slower compilation issue, because then you'd only pay for
 what you used.


That would probably even be a side-effect of the implementation of 
separately compiled templates (eagerly compiling them will require some 
additional code).


 Second, something must be done about memory allocation during
 compilation of diet templates. There's too much going on there.

 That's it for now.


See also https://issues.dlang.org/show_bug.cgi?id=6498



 Jun 10 2014



 next sibling parent reply "w0rp" <devw0rp gmail.com>  writes:


On Tuesday, 10 June 2014 at 08:12:53 UTC, Sönke Ludwig wrote:

 It's not heap allocations. The problem is that during CTFE, 
 currently basically every variable change allocates memory that 
 is never freed again. I've used a few tricks to get the memory 
 usage down (which is why the Diet compiler source code doesn't 
 look very pretty), but basically the only way to get reasonable 
 memory use is to fix the D front end.


Indeed, this is a front end issue. I'm considering switching to 
markdown files loaded at runtime for many pages. So I can create 
only a few diet templates for basic layout, two column, generic 
changelog template, etc, and then load Markdown content at 
runtime and parse Markdown for generating the table of contents 
automatically.



 Jun 10 2014



  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 10.06.2014 12:25, schrieb w0rp:

 On Tuesday, 10 June 2014 at 08:12:53 UTC, Sönke Ludwig wrote:

 It's not heap allocations. The problem is that during CTFE, currently
 basically every variable change allocates memory that is never freed
 again. I've used a few tricks to get the memory usage down (which is
 why the Diet compiler source code doesn't look very pretty), but
 basically the only way to get reasonable memory use is to fix the D
 front end.


 Indeed, this is a front end issue. I'm considering switching to markdown
 files loaded at runtime for many pages. So I can create only a few diet
 templates for basic layout, two column, generic changelog template, etc,
 and then load Markdown content at runtime and parse Markdown for
 generating the table of contents automatically.


If you go down the Markdown route*, let's extend the 
vibe.textfilter.markdown module to output structural information. 
Writing a Markdown parser in a way that doesn't use a cascade of regex 
patterns is definitely nothing I'd recommend anyone to try to do, unless 
absolutely necessary - it's awful.

* Are there any other opinions on this? I remember that there have been 
some strong proponents of using DDOC for things, so it would be bad if 
in the end Markdown were to be dropped, after all of the work has 
already been done. Personally I'd strongly favor Markdown, though.



 Jun 10 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:

 * Are there any other opinions on this? I remember that there 
 have been some strong proponents of using DDOC for things, so 
 it would be bad if in the end Markdown were to be dropped, 
 after all of the work has already been done. Personally I'd 
 strongly favor Markdown, though.


DDOC was promoted because of dog-fooding rationale but I believe 
it has unacceptable learning curve and negatively impacts 
documentation contribution.



 Jun 10 2014



 next sibling parent  "w0rp" <devw0rp gmail.com>  writes:


On Tuesday, 10 June 2014 at 11:09:23 UTC, Dicebot wrote:

 On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:

 * Are there any other opinions on this? I remember that there 
 have been some strong proponents of using DDOC for things, so 
 it would be bad if in the end Markdown were to be dropped, 
 after all of the work has already been done. Personally I'd 
 strongly favor Markdown, though.


 DDOC was promoted because of dog-fooding rationale but I 
 believe it has unacceptable learning curve and negatively 
 impacts documentation contribution.


I think the key advantage for Markdown is that it's well 
understood by a larger community, (GitHub, Stack Overflow, 
Reddit, etc.) so it would likely encourage contribution to 
editing pages on the website. It's also just has very nice syntax 
for writing articles with, although I know how frustrating it is 
to write a parser for it. (You have to accept stuff which is 
sometimes HTML, sometimes not.)

The library documentation will still be DDoc generated, as that's 
the best tool for that, just styled differently.



 Jun 10 2014



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 10/06/14 13:09, Dicebot wrote:


 DDOC was promoted because of dog-fooding rationale but I believe it has
 unacceptable learning curve and negatively impacts documentation
 contribution.


I think Ddoc is fine for API documentation, but not for designing a web 
site.

-- 
/Jacob Carlborg



 Jun 10 2014



prev sibling next sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com>  writes:


On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:

 Am 10.06.2014 12:25, schrieb w0rp:

 On Tuesday, 10 June 2014 at 08:12:53 UTC, Sönke Ludwig wrote:

 It's not heap allocations. The problem is that during CTFE, 
 currently
 basically every variable change allocates memory that is 
 never freed
 again. I've used a few tricks to get the memory usage down 
 (which is
 why the Diet compiler source code doesn't look very pretty), 
 but
 basically the only way to get reasonable memory use is to fix 
 the D
 front end.


 Indeed, this is a front end issue. I'm considering switching 
 to markdown
 files loaded at runtime for many pages. So I can create only a 
 few diet
 templates for basic layout, two column, generic changelog 
 template, etc,
 and then load Markdown content at runtime and parse Markdown 
 for
 generating the table of contents automatically.


 If you go down the Markdown route*, let's extend the 
 vibe.textfilter.markdown module to output structural 
 information. Writing a Markdown parser in a way that doesn't 
 use a cascade of regex patterns is definitely nothing I'd 
 recommend anyone to try to do, unless absolutely necessary - 
 it's awful.

 * Are there any other opinions on this? I remember that there 
 have been some strong proponents of using DDOC for things, so 
 it would be bad if in the end Markdown were to be dropped, 
 after all of the work has already been done. Personally I'd 
 strongly favor Markdown, though.


Definitely support Markdown.

DDoc is extremely discouraging/making bad first impression on 
newbies, especially for people who want to write web content.

(But I'd recommend extended GitHub-like markdown if possible, 
plain markdown is pretty bare bones. Personally I use 
ReStructuredText but I think the GitHub markdown is pretty good 
and most potential contributors can already write it without 
learning a new format.



 Jun 10 2014



 next sibling parent  Russel Winder via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Tue, 2014-06-10 at 12:31 +0000, Kiith-Sa via Digitalmars-d wrote:

 On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:


[…]

 * Are there any other opinions on this? I remember that there 
 have been some strong proponents of using DDOC for things, so 
 it would be bad if in the end Markdown were to be dropped, 
 after all of the work has already been done. Personally I'd 
 strongly favor Markdown, though.




Isn't DDoc for generating API documentation is the vein of Doxygen,
JavaDoc, etc., and isn't this discussion about generating general
(albeit technical) webpages?


 Definitely support Markdown.
 
 DDoc is extremely discouraging/making bad first impression on 
 newbies, especially for people who want to write web content.
 
 (But I'd recommend extended GitHub-like markdown if possible, 
 plain markdown is pretty bare bones. Personally I use 
 ReStructuredText but I think the GitHub markdown is pretty good 
 and most potential contributors can already write it without 
 learning a new format.


The Groovy community initially tried using GrailsDoc – not an API
documentation system, but a way of writing general documentation that
could easily access API documentation. However, the move now appears to
be to ASCIIDoc using the ASCIIDoctor toolchain.

As for ReStructured Text, I find Markdown beats it for short pages, but
it beats Markdown easily for bigger documents. The Sphinx system may not
be appropriate for D, but it works very well.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jun 10 2014



prev sibling  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 10.06.2014 14:31, schrieb Kiith-Sa:

 (But I'd recommend extended GitHub-like markdown if possible, plain
 markdown is pretty bare bones. Personally I use ReStructuredText but I
 think the GitHub markdown is pretty good and most potential contributors
 can already write it without learning a new format.


Agreed. The Markdown parser in vibe.d does support some of the GitHub 
extensions, but still lacks some useful things like tables.



 Jun 10 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Tuesday, 10 June 2014 at 14:50:51 UTC, Sönke Ludwig wrote:

 Am 10.06.2014 14:31, schrieb Kiith-Sa:

 (But I'd recommend extended GitHub-like markdown if possible, 
 plain
 markdown is pretty bare bones. Personally I use 
 ReStructuredText but I
 think the GitHub markdown is pretty good and most potential 
 contributors
 can already write it without learning a new format.


 Agreed. The Markdown parser in vibe.d does support some of the 
 GitHub extensions, but still lacks some useful things like 
 tables.


I can definitely live without Markdown style tables. I'm happy 
enough to write HTML for that.



 Jun 10 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


I thought I'd post an update on this work so I don't leave any 
people hanging who are wondering about this.

I haven't had the time in the last week or so to work on this as 
I have been very busy recently with other responsibilities. With 
my day job in particular, I will be in Berlin most of next week 
hosting a conference with my company. Because it's a small world, 
by pure coincidence Sociomantic are actually sponsoring this 
conference. (I doubt the marketing guys talk to the D programmers 
that much, though.)

http://www.performancemarketinginsights.com/14/europe/sponsor/sociomantic/

However, after I get back I will defintely work on this redesign 
some more. Unless somebody pins me down, I'll keep going with it. 
I only just realised that I made the terrible mistake of not 
pushing my most recent changes, so you can find them now on 
GitHub.

I started working on discovering Markdown files at runtime for 
filling in a sections of pages, like center part of changelog 
pages, and generating the table of contents from the HTML 
automatically. Because the prospect of parsing HTML myself scares 
me, I just copied in Adam D Ruppe's DOM library for that. I hope 
that I have properly attributed the authors for that code, please 
advise me if I should add any additional attribution in there 
otherwise.

The early result of that I think has been pretty good. I can edit 
a file and see a change pretty quickly. I lost the functions I 
was using to generating the Bugzilla links, but I'm going to 
replacing them with links to /bug/<id> instead, and making that 
page redirect to the right place, just so I can make my Markdown 
files a little smaller. The amount of memory consumed while 
compiling is better, going from something like 2GB to 1.2GB, 
because there aren't tons of Diet templates to build in anymore. 
The Markdown parsing is just the library functionality that comes 
with vibe.d.

I totally have not converted all of the pages from Diet to 
Markdown yet. In fact, if you run the site as is now, you can't 
see any of the changelog pages except 2.000 anymore. Plus, you 
could perhaps do something involving caching files instead of 
loading them from the drive all the time, but I just want 
something that works for now.

So there's my update for now.



 Jun 20 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


I just finished translating all of the pages I have worked on so 
far from diet templates to Markdown files. Now there is only one 
diet layout loaded, and the rest is all Markdown files. This has 
dramatically reduced the amount of memory consumed at build time. 
You can see the results at the usual place at 
http://w0rp.com:8010 and view the source on GitHub. I'll keep at 
it and convert more pages from the main site.



 Jun 29 2014



 next sibling parent  David Gileadi <gileadis NSPMgmail.com>  writes:


On 6/29/14, 3:15 PM, w0rp wrote:

 I just finished translating all of the pages I have worked on so far
 from diet templates to Markdown files. Now there is only one diet layout
 loaded, and the rest is all Markdown files. This has dramatically
 reduced the amount of memory consumed at build time. You can see the
 results at the usual place at http://w0rp.com:8010 and view the source
 on GitHub. I'll keep at it and convert more pages from the main site.


This is looking really good!



 Jun 30 2014



prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:

 I just finished translating all of the pages I have worked on 
 so far from diet templates to Markdown files. Now there is only 
 one diet layout loaded, and the rest is all Markdown files. 
 This has dramatically reduced the amount of memory consumed at 
 build time. You can see the results at the usual place at 
 http://w0rp.com:8010 and view the source on GitHub. I'll keep 
 at it and convert more pages from the main site.


Please use the correct logo and the correct colours. Branding is 
extremely important!

http://media.sukimashita.com/d/d-5.svg



 Jun 30 2014



 next sibling parent  David Gileadi <gileadis NSPMgmail.com>  writes:


On 6/30/14, 2:11 PM, Gary Willoughby wrote:

 On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:

 I just finished translating all of the pages I have worked on so far
 from diet templates to Markdown files. Now there is only one diet
 layout loaded, and the rest is all Markdown files. This has
 dramatically reduced the amount of memory consumed at build time. You
 can see the results at the usual place at http://w0rp.com:8010 and
 view the source on GitHub. I'll keep at it and convert more pages from
 the main site.


 Please use the correct logo and the correct colours. Branding is
 extremely important!

 http://media.sukimashita.com/d/d-5.svg


My opinion is that the redesign preserves the spirit of the current logo 
while fitting in well with the flatter look. I think someone who sees 
the one logo will recognize the other in it (unlike some of the recent 
proposed logos).



 Jun 30 2014



prev sibling  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Monday, 30 June 2014 at 21:11:31 UTC, Gary Willoughby wrote:

 On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:

 I just finished translating all of the pages I have worked on 
 so far from diet templates to Markdown files. Now there is 
 only one diet layout loaded, and the rest is all Markdown 
 files. This has dramatically reduced the amount of memory 
 consumed at build time. You can see the results at the usual 
 place at http://w0rp.com:8010 and view the source on GitHub. 
 I'll keep at it and convert more pages from the main site.


 Please use the correct logo and the correct colours. Branding 
 is extremely important!

 http://media.sukimashita.com/d/d-5.svg


The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design 
experience. The old logo is a bit too fat and round to fit with 
the new design, so I'd like something which is obviously still 
the same brand, but looks a bit flatter.



 Jun 30 2014



 next sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design experience. The
 old logo is a bit too fat and round to fit with the new design, so I'd
 like something which is obviously still the same brand, but looks a bit
 flatter.


I just found out why your logo looks terrible on my machine, you are 
using a web font in the SVG that FF isn't finding and there is no 
fallback specified so I'm getting a D in Times New Roman ><

A quick solution would be to convert the glyph to curves ("Object to 
Path" on the "Path" menu in Inkscape), then you will know that everyone 
is seeing the same thing.

A...



 Jul 01 2014



 next sibling parent  Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 01/07/2014 8:40 AM, Alix Pexton wrote:

 On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design experience. The
 old logo is a bit too fat and round to fit with the new design, so I'd
 like something which is obviously still the same brand, but looks a bit
 flatter.


 I just found out why your logo looks terrible on my machine, you are
 using a web font in the SVG that FF isn't finding and there is no
 fallback specified so I'm getting a D in Times New Roman ><

 A quick solution would be to convert the glyph to curves ("Object to
 Path" on the "Path" menu in Inkscape), then you will know that everyone
 is seeing the same thing.

 A...


However, the font is Apache licensed, so to use it in a logo you would 
need to purchase the Pro version for $80 dollars. This is why I do all 
my own typography!

A...



 Jul 01 2014



prev sibling  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:

 On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design 
 experience. The
 old logo is a bit too fat and round to fit with the new 
 design, so I'd
 like something which is obviously still the same brand, but 
 looks a bit
 flatter.


 I just found out why your logo looks terrible on my machine, 
 you are using a web font in the SVG that FF isn't finding and 
 there is no fallback specified so I'm getting a D in Times New 
 Roman ><

 A quick solution would be to convert the glyph to curves 
 ("Object to Path" on the "Path" menu in Inkscape), then you 
 will know that everyone is seeing the same thing.

 A...


Ah, I didn't realise the SVG was loading a font for that, I
suppose it make perfect sense. Again, no graphic design
experience.

Generally for the logo, I'm looking for someone who does know
what they are doing with Inkscape or similar tools to produce
something which fits instead.



 Jul 01 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:

 On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:

 On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design 
 experience. The
 old logo is a bit too fat and round to fit with the new 
 design, so I'd
 like something which is obviously still the same brand, but 
 looks a bit
 flatter.


 I just found out why your logo looks terrible on my machine, 
 you are using a web font in the SVG that FF isn't finding and 
 there is no fallback specified so I'm getting a D in Times New 
 Roman ><

 A quick solution would be to convert the glyph to curves 
 ("Object to Path" on the "Path" menu in Inkscape), then you 
 will know that everyone is seeing the same thing.

 A...


 Ah, I didn't realise the SVG was loading a font for that, I
 suppose it make perfect sense. Again, no graphic design
 experience.

 Generally for the logo, I'm looking for someone who does know
 what they are doing with Inkscape or similar tools to produce
 something which fits instead.


I'll fix that in the interim by converting the font into a shape 
instead.



 Jul 01 2014



 next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 1 July 2014 13:40, w0rp via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:

 On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:

 On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design experience. The
 old logo is a bit too fat and round to fit with the new design, so I'd
 like something which is obviously still the same brand, but looks a bit
 flatter.



 I just found out why your logo looks terrible on my machine, you are
 using a web font in the SVG that FF isn't finding and there is no fallback
 specified so I'm getting a D in Times New Roman ><

 A quick solution would be to convert the glyph to curves ("Object to
 Path" on the "Path" menu in Inkscape), then you will know that everyone is
 seeing the same thing.

 A...



 Ah, I didn't realise the SVG was loading a font for that, I
 suppose it make perfect sense. Again, no graphic design
 experience.

 Generally for the logo, I'm looking for someone who does know
 what they are doing with Inkscape or similar tools to produce
 something which fits instead.



 I'll fix that in the interim by converting the font into a shape instead.



By the way, did you get round to implementing some sort of generic
watch routine?

I've bashed together a small generic FAM - could clean it up and send
it to the vibe.d guys to fix up and make it better.

Regards
Iain



 Jul 01 2014



 next sibling parent  "w0rp" <devw0rp gmail.com>  writes:


On Tuesday, 1 July 2014 at 14:23:00 UTC, Iain Buclaw via 
Digitalmars-d wrote:

 By the way, did you get round to implementing some sort of 
 generic
 watch routine?

 I've bashed together a small generic FAM - could clean it up 
 and send
 it to the vibe.d guys to fix up and make it better.

 Regards
 Iain


I did not. We are defintely writing very similar things, so if 
you've got something already that does the job feel free to add 
it in with a pull request or push it up to vibe.d so everyone can 
benefit from it. I'm focused on getting more of the existing site 
copied across and a bunch of style things at the moment.



 Jul 01 2014



prev sibling  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 01.07.2014 16:22, schrieb Iain Buclaw via Digitalmars-d:

 On 1 July 2014 13:40, w0rp via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:

 On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:

 On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design experience. The
 old logo is a bit too fat and round to fit with the new design, so I'd
 like something which is obviously still the same brand, but looks a bit
 flatter.



 I just found out why your logo looks terrible on my machine, you are
 using a web font in the SVG that FF isn't finding and there is no fallback
 specified so I'm getting a D in Times New Roman ><

 A quick solution would be to convert the glyph to curves ("Object to
 Path" on the "Path" menu in Inkscape), then you will know that everyone is
 seeing the same thing.

 A...



 Ah, I didn't realise the SVG was loading a font for that, I
 suppose it make perfect sense. Again, no graphic design
 experience.

 Generally for the logo, I'm looking for someone who does know
 what they are doing with Inkscape or similar tools to produce
 something which fits instead.



 I'll fix that in the interim by converting the font into a shape instead.



 By the way, did you get round to implementing some sort of generic
 watch routine?

 I've bashed together a small generic FAM - could clean it up and send
 it to the vibe.d guys to fix up and make it better.

 Regards
 Iain


If it works with libevent and could be fit into this API:

http://vibed.org/api/vibe.core.driver/EventDriver.watchDirectory
http://vibed.org/api/vibe.core.file/DirectoryWatcher

then that would be great! Live reloading is definitely a pretty big 
deal, but I've always been overloaded with work on more fundamental 
issues so far.

BTW, for the special case of Diet templates there is also this ticket:
https://github.com/rejectedsoftware/vibe.d/issues/676



 Jul 01 2014



  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 1 July 2014 20:05, Sönke Ludwig <digitalmars-d puremagic.com> wrote:

 Am 01.07.2014 16:22, schrieb Iain Buclaw via Digitalmars-d:

 On 1 July 2014 13:40, w0rp via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:

 On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:

 On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design experience.
 The
 old logo is a bit too fat and round to fit with the new design, so I'd
 like something which is obviously still the same brand, but looks a
 bit
 flatter.




 I just found out why your logo looks terrible on my machine, you are
 using a web font in the SVG that FF isn't finding and there is no
 fallback
 specified so I'm getting a D in Times New Roman ><

 A quick solution would be to convert the glyph to curves ("Object to
 Path" on the "Path" menu in Inkscape), then you will know that everyone
 is
 seeing the same thing.

 A...




 Ah, I didn't realise the SVG was loading a font for that, I
 suppose it make perfect sense. Again, no graphic design
 experience.

 Generally for the logo, I'm looking for someone who does know
 what they are doing with Inkscape or similar tools to produce
 something which fits instead.




 I'll fix that in the interim by converting the font into a shape instead.




 By the way, did you get round to implementing some sort of generic
 watch routine?

 I've bashed together a small generic FAM - could clean it up and send
 it to the vibe.d guys to fix up and make it better.

 Regards
 Iain


 If it works with libevent and could be fit into this API:

 http://vibed.org/api/vibe.core.driver/EventDriver.watchDirectory
 http://vibed.org/api/vibe.core.file/DirectoryWatcher

 then that would be great! Live reloading is definitely a pretty big deal,
 but I've always been overloaded with work on more fundamental issues so far.


It doesn't use libevent... yet.  As I said, its bashed together so
pretty much works as a separate thread running in a while(true) { ...
sleep(x); } loop that re-compiles markdown files in the background.

For the moment on my own staging site, I've just loaded in Redis as a
memserver with a brief expiry time.

Wouldn't want to steal the limelight, but I'm over here:

http://staging.dgnu.org

Regards
Iain



 Jul 01 2014



prev sibling  parent  "Brad Anderson" <eco gnuk.net>  writes:


On Tuesday, 1 July 2014 at 12:40:21 UTC, w0rp wrote:

 On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:

 On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:

 On 01/07/2014 7:42 AM, w0rp wrote:


 The logo on the site I'm testing is the most effective duck.

 The logo is a placeholder I made with no graphic design 
 experience. The
 old logo is a bit too fat and round to fit with the new 
 design, so I'd
 like something which is obviously still the same brand, but 
 looks a bit
 flatter.


 I just found out why your logo looks terrible on my machine, 
 you are using a web font in the SVG that FF isn't finding and 
 there is no fallback specified so I'm getting a D in Times 
 New Roman ><

 A quick solution would be to convert the glyph to curves 
 ("Object to Path" on the "Path" menu in Inkscape), then you 
 will know that everyone is seeing the same thing.

 A...


 Ah, I didn't realise the SVG was loading a font for that, I
 suppose it make perfect sense. Again, no graphic design
 experience.

 Generally for the logo, I'm looking for someone who does know
 what they are doing with Inkscape or similar tools to produce
 something which fits instead.


 I'll fix that in the interim by converting the font into a 
 shape instead.


I did that a couple years ago: http://goo.gl/trMh6k



 Jul 01 2014



prev sibling  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 30 June 2014 at 21:23:59 UTC, David Gileadi wrote:

 My opinion is that the redesign preserves the spirit of the 
 current logo while fitting in well with the flatter look. I 
 think someone who sees the one logo will recognize the other in 
 it (unlike some of the recent proposed logos).


On Tuesday, 1 July 2014 at 06:42:49 UTC, w0rp wrote:

 The logo is a placeholder I made with no graphic design 
 experience. The old logo is a bit too fat and round to fit with 
 the new design, so I'd like something which is obviously still 
 the same brand, but looks a bit flatter.


No! You must use the original D logo, this is not up for debate. 
I will fight this until the end. You cannot mess about with the 
brand! We must start to approach these things in a professional 
and respectful manner.

The original D logo (and colours) must be used.



 Jul 01 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 1 July 2014 at 08:34:30 UTC, Gary Willoughby wrote:

 On Monday, 30 June 2014 at 21:23:59 UTC, David Gileadi wrote:

 My opinion is that the redesign preserves the spirit of the 
 current logo while fitting in well with the flatter look. I 
 think someone who sees the one logo will recognize the other 
 in it (unlike some of the recent proposed logos).


 On Tuesday, 1 July 2014 at 06:42:49 UTC, w0rp wrote:

 The logo is a placeholder I made with no graphic design 
 experience. The old logo is a bit too fat and round to fit 
 with the new design, so I'd like something which is obviously 
 still the same brand, but looks a bit flatter.


 No! You must use the original D logo, this is not up for 
 debate. I will fight this until the end. You cannot mess about 
 with the brand! We must start to approach these things in a 
 professional and respectful manner.

 The original D logo (and colours) must be used.


Doing logo restyling together with web site update is not unheard 
of. Why do you see this a big deal? As long as it is recognizable 
and not fundamentally different of course. Having logo that 
simply does not fit into new design is worse.



 Jul 01 2014



  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-07-01 10:58, Dicebot wrote:


 Doing logo restyling together with web site update is not unheard of.
 Why do you see this a big deal? As long as it is recognizable and not
 fundamentally different of course. Having logo that simply does not fit
 into new design is worse.


Some companies also use different versions of their logo for different 
purposes. One on the website, one on print and so on.

-- 
/Jacob Carlborg



 Jul 01 2014



prev sibling next sibling parent  "David Nadlinger" <code klickverbot.at>  writes:


On Tuesday, 1 July 2014 at 08:34:30 UTC, Gary Willoughby wrote:

 No! You must use the original D logo, this is not up for 
 debate. I will fight this until the end. You cannot mess about 
 with the brand! We must start to approach these things in a 
 professional and respectful manner.

 The original D logo (and colours) must be used.


I'd say your zeal is a bit misdirected. "Professional" brands are 
relaunched all the time. For a small sampling, check 
http://blog.saijogeorge.com/big-brand-logo-redesign-success-failure-stories/.

David



 Jul 01 2014



prev sibling  parent reply "Brad Anderson" <eco gnuk.net>  writes:


On Tuesday, 1 July 2014 at 08:34:30 UTC, Gary Willoughby wrote:

 On Monday, 30 June 2014 at 21:23:59 UTC, David Gileadi wrote:

 My opinion is that the redesign preserves the spirit of the 
 current logo while fitting in well with the flatter look. I 
 think someone who sees the one logo will recognize the other 
 in it (unlike some of the recent proposed logos).


 On Tuesday, 1 July 2014 at 06:42:49 UTC, w0rp wrote:

 The logo is a placeholder I made with no graphic design 
 experience. The old logo is a bit too fat and round to fit 
 with the new design, so I'd like something which is obviously 
 still the same brand, but looks a bit flatter.


 No! You must use the original D logo, this is not up for 
 debate. I will fight this until the end. You cannot mess about 
 with the brand! We must start to approach these things in a 
 professional and respectful manner.

 The original D logo (and colours) must be used.


The copyright of the original isn't owned by Walter. I think it'd 
be best if we moved away from it. I like the flatter, cleaner 
logo.



 Jul 01 2014



  parent  Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 01/07/2014 6:08 PM, Brad Anderson wrote:
  The original D logo (and colours) must be used.

 The copyright of the original isn't owned by Walter. I think it'd be
 best if we moved away from it. I like the flatter, cleaner logo.


Should anyone ever deem one of my designs worthy, I'd be happy to sign 
over the copyright to Walter.

A...



 Jul 01 2014



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:

 I just finished translating all of the pages I have worked on 
 so far from diet templates to Markdown files. Now there is only 
 one diet layout loaded, and the rest is all Markdown files. 
 This has dramatically reduced the amount of memory consumed at 
 build time. You can see the results at the usual place at 
 http://w0rp.com:8010 and view the source on GitHub. I'll keep 
 at it and convert more pages from the main site.


I really appreciate quick links to current page headers added to 
the right side. Lack of this harms discoverability of existing 
docs a lot.



 Jul 01 2014



prev sibling  parent reply Shammah Chancellor <email domain.com>  writes:


On 2014-06-29 22:15:47 +0000, w0rp said:


 I just finished translating all of the pages I have worked on so far 
 from diet templates to Markdown files. Now there is only one diet 
 layout loaded, and the rest is all Markdown files. This has 
 dramatically reduced the amount of memory consumed at build time. You 
 can see the results at the usual place at http://w0rp.com:8010 and view 
 the source on GitHub. I'll keep at it and convert more pages from the 
 main site.


This looks awesome.  I like the new logo also.   Keep up the good work.

-Shammah



 Jul 01 2014



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Tuesday, 1 July 2014 at 11:25:49 UTC, Shammah Chancellor wrote:

 On 2014-06-29 22:15:47 +0000, w0rp said:


 I just finished translating all of the pages I have worked on 
 so far from diet templates to Markdown files. Now there is 
 only one diet layout loaded, and the rest is all Markdown 
 files. This has dramatically reduced the amount of memory 
 consumed at build time. You can see the results at the usual 
 place at http://w0rp.com:8010 and view the source on GitHub. 
 I'll keep at it and convert more pages from the main site.


 This looks awesome.  I like the new logo also.   Keep up the 
 good work.

 -Shammah


It is not about liking it or not...



 Jul 02 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


I just brought the Twitter module back. I decided to run with 
looking for '.sidebar.md' files as an easy way of dropping in 
different sidebar content for particular pages, so the index uses 
this now. I also brought the paragraph markers for the headings 
back. That should bring Markdown stuff to a level where I can 
drop in a bunch of pages now.

I put the logo my co-worker contributed in place there, which 
looks a bit more familiar. I'll leave the logo like that for now.



 Jul 02 2014



 next sibling parent  "Suliman" <evermind live.ru>  writes:


I think it's better to remove mention about D1 on main page. It's 
not actual and present time. But now it's took to many space...



 Jul 02 2014



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:

 I just brought the Twitter module back.


:( it was so much better with this ugly widget gone and replaced 
with something actually useful.



 Jul 03 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:

 On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:

 I just brought the Twitter module back.


 :( it was so much better with this ugly widget gone and 
 replaced with something actually useful.


I actually didn't intend to remove it before, but if we want to 
replace it with something else I could do that. I don't feel 
strongly either way about it.



 Jul 03 2014



 next sibling parent  Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 03/07/2014 12:35 PM, w0rp wrote:

 On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:

 On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:

 I just brought the Twitter module back.


 :( it was so much better with this ugly widget gone and replaced with
 something actually useful.


 I actually didn't intend to remove it before, but if we want to replace
 it with something else I could do that. I don't feel strongly either way
 about it.


The twitter feed on D currently fulfils the role that in other places is 
performed by an internal news ticker that summarises the most recent 
news stories. D for some reason does not seem to generate that much 
internal news, at least not in a form that would be apt for consumption 
on the dlang.org landing page.

Maybe if the forum front end produced an RSS feed of top level posts to 
d.announce that could be fed into the buzz box. Then all we'd need is a 
steady stream of exciting announcements.

A...



 Jul 03 2014



prev sibling  parent  "Dicebot" <public dicebot.lv>  writes:


On Thursday, 3 July 2014 at 11:35:36 UTC, w0rp wrote:

 On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:

 On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:

 I just brought the Twitter module back.


 :( it was so much better with this ugly widget gone and 
 replaced with something actually useful.


 I actually didn't intend to remove it before, but if we want to 
 replace it with something else I could do that. I don't feel 
 strongly either way about it.


I'd prefer to see it removed but pretty sure many will be against 
it. Even if we keep it as replacement for proper newsfeed, I'd 
love to see it formatted the same way as main content and not as 
side block widget (== no scrollbars, light background, no 
repeating logos, no "follow" button etc)



 Jul 03 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 6/10/14, 3:42 AM, Sönke Ludwig wrote:

 * Are there any other opinions on this? I remember that there have been
 some strong proponents of using DDOC for things, so it would be bad if
 in the end Markdown were to be dropped, after all of the work has
 already been done. Personally I'd strongly favor Markdown, though.


I think ddoc is a lot more flexible than markdown, and I'm baffled by 
the claim that ddoc is difficult to learn. That said I do agree it's a 
turnoff for first-time website contributors. IMHO if we switch away from 
ddoc we should switch to something better, not something just different. 
-- Andrei



 Jun 10 2014



 next sibling parent  Jacob Carlborg <doob me.com>  writes:


On 10/06/14 16:06, Andrei Alexandrescu wrote:


 I think ddoc is a lot more flexible than markdown, and I'm baffled by
 the claim that ddoc is difficult to learn. That said I do agree it's a
 turnoff for first-time website contributors. IMHO if we switch away from
 ddoc we should switch to something better, not something just different.


Something better/more powerful would be something backed by a proper 
programming language.

-- 
/Jacob Carlborg



 Jun 10 2014



prev sibling next sibling parent  =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 10.06.2014 16:06, schrieb Andrei Alexandrescu:

 On 6/10/14, 3:42 AM, Sönke Ludwig wrote:

 * Are there any other opinions on this? I remember that there have been
 some strong proponents of using DDOC for things, so it would be bad if
 in the end Markdown were to be dropped, after all of the work has
 already been done. Personally I'd strongly favor Markdown, though.


 I think ddoc is a lot more flexible than markdown, and I'm baffled by
 the claim that ddoc is difficult to learn. That said I do agree it's a
 turnoff for first-time website contributors. IMHO if we switch away from
 ddoc we should switch to something better, not something just different.
 -- Andrei


Markdown has the advantages of a semantic content representation - so 
while it doesn't have a flexible macro system, external processors can 
be used to transform it into any desired output format (including binary 
or white space sensitive formats).

But the key points for me would be better readability and its broad 
prevalence among the general developer community. One possibly major 
consequence of this is tool support. For example, GitHub has a built-in 
editor with preview for Markdown documents, so that anyone with a GitHub 
account can quickly edit page contents without having to clone or build 
the site.



 Jun 10 2014



prev sibling  parent reply "Steven Schveighoffer" <schveiguy yahoo.com>  writes:


On Tue, 10 Jun 2014 10:06:57 -0400, Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org> wrote:


 On 6/10/14, 3:42 AM, S=C3=B6nke Ludwig wrote:

 * Are there any other opinions on this? I remember that there have be=




en

 some strong proponents of using DDOC for things, so it would be bad i=




f

 in the end Markdown were to be dropped, after all of the work has
 already been done. Personally I'd strongly favor Markdown, though.


 I think ddoc is a lot more flexible than markdown, and I'm baffled by =


 =


 the claim that ddoc is difficult to learn. That said I do agree it's a=


  =


 turnoff for first-time website contributors. IMHO if we switch away fr=


om  =


 ddoc we should switch to something better, not something just differen=


t.

Markdown can be instantly understood by anyone who sees it. DDOC require=
s  =

lookup/learning, even if you know how DDOC works, you still have to figu=
re  =

out what all the macros mean and do. And none of that is documented as f=
ar  =

as I know.

Flexibility isn't everything. The goal is to make it easy to be an autho=
r.

-Steve



 Jun 10 2014



  parent  "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 10 June 2014 at 14:54:32 UTC, Steven Schveighoffer 
wrote:

 Markdown can be instantly understood by anyone who sees it. 
 DDOC requires lookup/learning, even if you know how DDOC works, 
 you still have to figure out what all the macros mean and do. 
 And none of that is documented as far as I know.

 Flexibility isn't everything. The goal is to make it easy to be 
 an author.


This. I use DDOC for actual documentation daily and still was 
reluctant to spend time on figuring out what all those macros 
mean and how to use those. Better spend time on something both 
interesting and useful.

Flexibility is hardly important at all here.



 Jun 10 2014



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 10/06/14 10:12, Sönke Ludwig wrote:


 But yes, it's definitely not what you want to have for D. I'm not sure
 how much can be done about that, though - except from rewriting the CTFE
 engine with performance in mind (maybe even using a JIT compiler). Or
 maybe it's possible to be more liberal with algorithmic optimizations
 when the CTFE memory usage brought to a reasonable level.


Can the templates be compiled in a separate phase, not using CTFE but as 
a regular compiler?

-- 
/Jacob Carlborg



 Jun 10 2014



  parent reply "Puming" <zhaopuming gmail.com>  writes:


On Tuesday, 10 June 2014 at 11:09:41 UTC, Jacob Carlborg wrote:

 On 10/06/14 10:12, Sönke Ludwig wrote:


 But yes, it's definitely not what you want to have for D. I'm 
 not sure
 how much can be done about that, though - except from 
 rewriting the CTFE
 engine with performance in mind (maybe even using a JIT 
 compiler). Or
 maybe it's possible to be more liberal with algorithmic 
 optimizations
 when the CTFE memory usage brought to a reasonable level.


 Can the templates be compiled in a separate phase, not using 
 CTFE but as a regular compiler?


Or, just like ctRegx vs regx, can we have a runtime version of 
diet template that runs slower but doesn't need to compile? It 
would be great for development phase.



 Jun 10 2014



  parent  "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 10 June 2014 at 11:35:32 UTC, Puming wrote:

 On Tuesday, 10 June 2014 at 11:09:41 UTC, Jacob Carlborg wrote:

 On 10/06/14 10:12, Sönke Ludwig wrote:


 But yes, it's definitely not what you want to have for D. I'm 
 not sure
 how much can be done about that, though - except from 
 rewriting the CTFE
 engine with performance in mind (maybe even using a JIT 
 compiler). Or
 maybe it's possible to be more liberal with algorithmic 
 optimizations
 when the CTFE memory usage brought to a reasonable level.


 Can the templates be compiled in a separate phase, not using 
 CTFE but as a regular compiler?


 Or, just like ctRegx vs regx, can we have a runtime version of 
 diet template that runs slower but doesn't need to compile? It 
 would be great for development phase.


We can't because Diet templates may contain arbitrary D code 
inline.



 Jun 10 2014



prev sibling next sibling parent reply Jacob Carlborg <doob me.com>  writes:


On 31/05/14 21:49, w0rp wrote:

 After watching Andrei's keynote where he was asking for help, and
 noticing that there wasn't any proof of someone working on this, I took
 charge.

 http://w0rp.com:8010/


I kind of like it. It would be nice to see examples of a couple of other 
pages as well. The menus are removed when the width of the page gets too 
small. I assume they're supposed to become a collapsed drop down menu 
like this: http://getbootstrap.com/examples/starter-template/


 That's the design in the form of a single page website running on my
 Linode. The source is available here.

 https://github.com/w0rp/new-dlang.org

 I would like to keep going with this and just redesign the whole
 website. A few points worth noting.

 * This is entirely a vibe.d website. (See the source.)
 * For pages, DDoc is replaced with diet templates.


Yes, thank you, finally.


 Those seconds in between making a change and seeing the results really
 build up over time. It's probably hard to describe without trying it
 yourself, but trust me, it matters. This is the kind of thing I have
 recently fought against at work, and it was well worth it. I replaced a
 Compass filesystem monitor with an even slightly broken libsass CPython
 compiler which compiled SCSS based on modification times. The couple
 seconds of difference has definitely improved the day-to-day life of
 myself and the web designer I work with.


Try that with livereload as well. For CSS it doesn't need to reload the 
whole page, it just inserts the new CSS.


-- 
/Jacob Carlborg



 Jun 02 2014



  parent  "w0rp" <devw0rp gmail.com>  writes:


On Monday, 2 June 2014 at 12:28:53 UTC, Jacob Carlborg wrote:

 I kind of like it. It would be nice to see examples of a couple 
 of other pages as well. The menus are removed when the width of 
 the page gets too small. I assume they're supposed to become a 
 collapsed drop down menu like this: 
 http://getbootstrap.com/examples/starter-template/


Yes, I plan to follow the usual pattern for having a drop down 
menu for small screens, I just haven't impelemented it yet. 
(Bootstrap should make this easy.)


 ...


 Try that with livereload as well. For CSS it doesn't need to 
 reload the whole page, it just inserts the new CSS.


I don't need to recompile when I make CSS changes thankfully, but 
a lot of experimenting with page layout means rapidly changing 
page content, so that means changing HTML. The problem isn't too 
severe, but the cycle could be made a bit tighter with automatic 
recompilation of diet templates, which Sönke says is possible 
with about a week of work or so. (Sönke is *the man* and has 
addressed a lot of my concerns in a timely manner in the past.)



 Jun 02 2014



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:

 After watching Andrei's keynote where he was asking for help, 
 and noticing that there wasn't any proof of someone working on 
 this, I took charge.

 http://w0rp.com:8010/


Looks good! Can twitter widget be forced to rescale on wider 
screens? It looks very annoying right now with scroll-bar and lot 
of line breaks when half of the space is still available.


 * For pages, DDoc is replaced with diet templates.


If this will happen, I will actually start to contribute to 
documentation :)



 Jun 02 2014



  parent  Jacob Carlborg <doob me.com>  writes:


On 2014-06-02 16:45, Dicebot wrote:


 If this will happen, I will actually start to contribute to
 documentation :)


Agree. This would also make a reason for me to learn vibe.d.

-- 
/Jacob Carlborg



 Jun 02 2014



prev sibling next sibling parent  "Uranuz" <neuranuz gmail.com>  writes:


On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 Hello,

 I've been D enthusiast for couple of years now (but I do not 
 participate much in discussions here, although I read forums 
 almost daily), and I keep telling people about D and how 
 awesome it is.

 But, all this time D's official website somehow archaic look 
 kept troubling me. It reminds me of early 2000's design and I 
 really cannot associate this design with "modern" or "elegant", 
 what D really is.
 I think that we must invest time and energy improving the 
 website's look and feel as that is what people first coming to 
 D will see. We need to strive for "wow" and not "meh" as a 
 first impression.

 So I have started this thread to see if there is a chance for 
 complete redesign of dlang.org.

 I have also tried to design something myself (although I'm not 
 a designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?




 -- Aleksandar


Looks pretty well. What I don't like is dark background for 
section of code. I prefer reading text on light background. But 
tastes differ! For example OS console on Windows or Linux is 
usually has dark background.



 Jul 01 2014



prev sibling next sibling parent reply "Chris" <wendlec tcd.ie>  writes:


On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 Hello,

 I've been D enthusiast for couple of years now (but I do not 
 participate much in discussions here, although I read forums 
 almost daily), and I keep telling people about D and how 
 awesome it is.

 But, all this time D's official website somehow archaic look 
 kept troubling me. It reminds me of early 2000's design and I 
 really cannot associate this design with "modern" or "elegant", 
 what D really is.
 I think that we must invest time and energy improving the 
 website's look and feel as that is what people first coming to 
 D will see. We need to strive for "wow" and not "meh" as a 
 first impression.

 So I have started this thread to see if there is a chance for 
 complete redesign of dlang.org.

 I have also tried to design something myself (although I'm not 
 a designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?




 -- Aleksandar


[I haven't had time to follow the entire thread, but] I like the 
design, it's a good starting point. Especially the integration of 
the logo. Nice and clean. (The current logo is just too bulky and 
clumsy, imo*)

However, my experience tells me that we should wait with 
redesigning it until the technical issues/problems have been 
solved, e.g. the migration to vibe.d, which I'm in favor of (I've 
had good experiences with vibe.d so far), and the doc generation 
issue etc etc. Once that is out of the way, we can think about 
new designs. Yours is very nice and "modern". However, we also 
have to take mobile devices (tablets, smartphones) into account 
and see how we can adapt to these (different layouts or one for 
all?).

Another issue is that we don't have to jump on any bandwagon 
(every time the "fashion" changes), we can roll our own design, 
one that fits the community's and the language's needs, 
regardless of what is trendy or "modern" at any given time (don't 
imitate, innovate!).

My two cents anyway ...

*(D is already a bulky letter, so there shouldn't be much else on 
the logo)



 Jul 03 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:

 [I haven't had time to follow the entire thread, but] I like 
 the design, it's a good starting point. Especially the 
 integration of the logo. Nice and clean. (The current logo is 
 just too bulky and clumsy, imo*)

 However, my experience tells me that we should wait with 
 redesigning it until the technical issues/problems have been 
 solved, e.g. the migration to vibe.d, which I'm in favor of 
 (I've had good experiences with vibe.d so far), and the doc 
 generation issue etc etc. Once that is out of the way, we can 
 think about new designs.


I've been focusing on getting a working site with vibe.d. 
Integrating the ddox document generator is a high priority for me 
right now, especially since I've finished a lot of work for 
formatting the changelog pages.


 Yours is very nice and "modern". However, we also have to take 
 mobile devices (tablets, smartphones) into account and see how 
 we can adapt to these (different layouts or one for all?).


I used the Bootstrap framework, which I have also used in my day 
job. Bootstrap makes producing a responsive design pretty easy. 
I've been periodically testing pages on smaller screens. 
Firefox's 'reponsive design mode' helps a lot with this.


 Another issue is that we don't have to jump on any bandwagon 
 (every time the "fashion" changes), we can roll our own design, 
 one that fits the community's and the language's needs, 
 regardless of what is trendy or "modern" at any given time 
 (don't imitate, innovate!).


There are many different designs you could produce. Many design 
choices are subjective, though not all of them. I think my goals 
for the work I've been doing are as follows.

* Improve site navigation.
* Improve display across different devices.
* Improve the quality of text to make it easier to read.
* Make it easier for newcomers to edit, to encourage contribution.
* Run it all with D to tick a "official D site made in D" 
checkbox.

There are others, but those are the important ones.



 Jul 03 2014



 next sibling parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 03/07/2014 6:38 PM, w0rp wrote:


 * Run it all with D to tick a "official D site made in D" checkbox.


The "powered by Python" banner gave me an idea...

In a nod to Walter's self confessed petrol-headedness, I thought we 
could incorporate the logo into a "D under the hood" or "D in the tank" 
banner for sites and software that utilise or run on D.

Might be a bit over the top for dlang.org though ^^

A...



 Jul 03 2014



 next sibling parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 3 Jul 2014 20:45, "Alix Pexton via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On 03/07/2014 6:38 PM, w0rp wrote:


 * Run it all with D to tick a "official D site made in D" checkbox.



 The "powered by Python" banner gave me an idea...

 In a nod to Walter's self confessed petrol-headedness, I thought we could


incorporate the logo into a "D under the hood" or "D in the tank" banner
for sites and software that utilise or run on D.

 Might be a bit over the top for dlang.org though ^^

 A...


Powered by Martian Technology



 Jul 03 2014



prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
[…]

 Powered by Martian Technology


 SarcasticRover is telling us "Do not come to Mars." Perhaps its
commentary need censoring ;-)
 
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



 Jul 04 2014



  parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via
Digitalmars-d wrote:

 On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via 
 Digitalmars-d wrote:
 […]

 Powered by Martian Technology


  SarcasticRover is telling us "Do not come to Mars." Perhaps its
 commentary need censoring ;-)
 


He also get angry when you mention that using the imperial system
is idiotic.



 Jul 08 2014



  parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 8 July 2014 21:20, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via

 Digitalmars-d wrote:

 On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
 […]

 Powered by Martian Technology



  SarcasticRover is telling us "Do not come to Mars." Perhaps its
 commentary need censoring ;-)


 He also get angry when you mention that using the imperial system
 is idiotic.


But the imperial system *isn't* idiotic. :o)

And everyone should drive on the left.



 Jul 08 2014



 next sibling parent  Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 08/07/2014 10:01 PM, Iain Buclaw via Digitalmars-d wrote:

 But the imperial system *isn't* idiotic. :o)


14 lbs is a stone? apart from that its fine ^^


 And everyone should drive on the left.


I drive in the middle, it works fine until I meet other road users.

A...



 Jul 08 2014



prev sibling  parent reply "Chris" <wendlec tcd.ie>  writes:


On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via 
Digitalmars-d wrote:

 On 8 July 2014 21:20, deadalnix via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via

 Digitalmars-d wrote:

 On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via 
 Digitalmars-d wrote:
 […]

 Powered by Martian Technology



  SarcasticRover is telling us "Do not come to Mars." Perhaps 
 its
 commentary need censoring ;-)


 He also get angry when you mention that using the imperial 
 system
 is idiotic.


 But the imperial system *isn't* idiotic. :o)

 And everyone should drive on the left.


Driving on the left goes back to the times when coaches 
(carriages) were still in use. This was to avoid that drivers 
would accidentally hit each other with their whips when a coach 
would come from the opposite direction. No joke. As regards cars, 
driving on the left is highly unintuitive for most people as the 
majority of drivers are right-handed. There is no ergonomic or 
technical reason why cars should drive on the left. In most parts 
of the world driving on the right was adopted from early on as it 
is more intuitive (for most people).



 Jul 09 2014



  parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 09/07/2014 12:36 PM, Chris wrote:

 On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via Digitalmars-d



 And everyone should drive on the left.


 Driving on the left goes back to the times when coaches (carriages) were
 still in use. This was to avoid that drivers would accidentally hit each
 other with their whips when a coach would come from the opposite
 direction. No joke. As regards cars, driving on the left is highly
 unintuitive for most people as the majority of drivers are right-handed.
 There is no ergonomic or technical reason why cars should drive on the
 left. In most parts of the world driving on the right was adopted from
 early on as it is more intuitive (for most people).


Driving on the left actually originates from jousting. On a tilting yard 
each combatant rides on the right side and aims their lance across their 
body at the opponent in the lane on the left. When knights passed each 
other out on the roads, the would do so on the left side so show that 
they were not hostile. The whole of Europe took up this practice, and 
used to always ride, drive carts and march as a body of men on the left.

Then a chap called Napoleon came along and used a guerilla tactic to 
trick his enemy by marching on the right so that his troops looked like 
they were travelling in the opposite direction. Eventually driving on 
the wrong side became the norm for all the regions of Europe that 
Napoleon conquered, and it spread as a matter of practicality to 
adjacent regions over time. Napoleon was defeated by the English because 
this trick does not work at sea. The UK still drives on the correct side 
because there is no problem with having to swap sides when crossing land 
borders. It is also an act that commemorates that historic victory.

Or at least that is what I learned in school ^^

A...



 Jul 09 2014



  parent reply "Chris" <wendlec tcd.ie>  writes:


On Wednesday, 9 July 2014 at 15:34:03 UTC, Alix Pexton wrote:

 On 09/07/2014 12:36 PM, Chris wrote:

 On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via 
 Digitalmars-d



 And everyone should drive on the left.


 Driving on the left goes back to the times when coaches 
 (carriages) were
 still in use. This was to avoid that drivers would 
 accidentally hit each
 other with their whips when a coach would come from the 
 opposite
 direction. No joke. As regards cars, driving on the left is 
 highly
 unintuitive for most people as the majority of drivers are 
 right-handed.
 There is no ergonomic or technical reason why cars should 
 drive on the
 left. In most parts of the world driving on the right was 
 adopted from
 early on as it is more intuitive (for most people).


 Driving on the left actually originates from jousting. On a 
 tilting yard each combatant rides on the right side and aims 
 their lance across their body at the opponent in the lane on 
 the left. When knights passed each other out on the roads, the 
 would do so on the left side so show that they were not 
 hostile. The whole of Europe took up this practice, and used to 
 always ride, drive carts and march as a body of men on the left.

 Then a chap called Napoleon came along and used a guerilla 
 tactic to trick his enemy by marching on the right so that his 
 troops looked like they were travelling in the opposite 
 direction. Eventually driving on the wrong side became the norm 
 for all the regions of Europe that Napoleon conquered, and it 
 spread as a matter of practicality to adjacent regions over 
 time. Napoleon was defeated by the English because this trick 
 does not work at sea. The UK still drives on the correct side 
 because there is no problem with having to swap sides when 
 crossing land borders. It is also an act that commemorates that 
 historic victory.

 Or at least that is what I learned in school ^^

 A...


This sounds just like Imperial education. Very interesting how it 
equates Imperial practices with the "right" thing and the 
(continental) arch enemy with the "wrong" thing. By the way, 
there was a reason why combatant riders would ride on the right 
side on a tilting yard: they were right-handed. Just as it makes 
more sense to switch gears with the right hand and not with the 
(in most cases) weaker left hand.



 Jul 09 2014



  parent reply Alix Pexton <alix.DOT.pexton gmail.DOT.com>  writes:


On 09/07/2014 4:43 PM, Chris wrote:

 This sounds just like Imperial education. Very interesting how it
 equates Imperial practices with the "right" thing and the (continental)
 arch enemy with the "wrong" thing. By the way, there was a reason why
 combatant riders would ride on the right side on a tilting yard: they
 were right-handed. Just as it makes more sense to switch gears with the
 right hand and not with the (in most cases) weaker left hand.



Sorry, the correct side/wrong side designations was all me, I have 
trouble with light and reft, and didn't want to get mixed up with the 2 
meanings of right. Perhaps its an artefact of my imperial education ^^

Also some argue that it makes more sense in a modern car to change gear 
with the left hand and keep the stronger arm on the steering wheel. 
Early right-hand-drive cars either had all foot operated gears, or they 
were on the outside (actually outside the cockpit) rather than in the 
middle because they needed real effort, modern gears especially 
automatics don't need that effort any more.

A...



 Jul 09 2014



  parent reply "Chris" <wendlec tcd.ie>  writes:


On Wednesday, 9 July 2014 at 21:20:28 UTC, Alix Pexton wrote:

 On 09/07/2014 4:43 PM, Chris wrote:

 This sounds just like Imperial education. Very interesting how 
 it
 equates Imperial practices with the "right" thing and the 
 (continental)
 arch enemy with the "wrong" thing. By the way, there was a 
 reason why
 combatant riders would ride on the right side on a tilting 
 yard: they
 were right-handed. Just as it makes more sense to switch gears 
 with the
 right hand and not with the (in most cases) weaker left hand.



 Sorry, the correct side/wrong side designations was all me, I 
 have trouble with light and reft, and didn't want to get mixed 
 up with the 2 meanings of right. Perhaps its an artefact of my 
 imperial education ^^


I see. Your account of what you learned is interesting 
nevertheless, because it implies that the Empire kept the ancient 
system, whereas now a new "corrupt" system is used in the rest of 
the world, a system that has its roots in the "insidious" tactics 
of a Frenchman called Napoleon.


 Also some argue that it makes more sense in a modern car to 
 change gear with the left hand and keep the stronger arm on the 
 steering wheel. Early right-hand-drive cars either had all foot 
 operated gears, or they were on the outside (actually outside 
 the cockpit) rather than in the middle because they needed real 
 effort, modern gears especially automatics don't need that 
 effort any more.

 A...


I don't agree. A lot of cars still use manual gears, not 
automatics. I also find that in dangerous situations it is better 
that the stronger arm has more room for action in the cockpit and 
is not impeded by the window / door. Also, pressing buttons on 
the radio / audio player, air conditioning etc. is much easier 
(=precise) with the stronger arm, especially while driving when 
these actions cannot get your undivided attention. This is at 
least my experience, but many people have agreed with me on this.



 Jul 10 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


http://w0rp.com:8010/library/index.html

I just updated the site hosted there with the work I've done on 
integrating the library documentation to date. I spent a lot of 
time staring at the pages for a while trying to figure out how to 
fit everything on a page decent. I admit to hacking the 
std.algoritm tables into not being tables, etc. I would very much 
appreciate any pull requests which improve on what I've done so 
far with it. It's all on GitHub in the usual place.

https://github.com/w0rp/new-dlang.org

Right now I'm using some of the layouts modified from Sönke's 
ddox templates, some modified from the dlang.org stuff. I'm using 
Adam D. Ruppe's DOM library, etc. I would like to properly 
attribute everyone for everything, so I would really appreciate 
input on where to credit people if I missed anything out. I have 
a COPYRIGHT file I can add people to if needed for that purpose, 
and I have retained the copyright comments in the arsd library.

I still haven't included syntax highlighting. This really isn't 
hard, I just haven't gotten around to doing it yet.

There's still a lot of work to be done, but it's one step closer 
now.



 Jul 26 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


..and fixed width docs again. Unfortunately I am not competent 
enough to propose any change so user CSS it stays for me :(

All pages seem to miss all examples - simply not implemented yet 
or oversight?



 Jul 26 2014



  parent  "Dicebot" <public dicebot.lv>  writes:


On Sunday, 27 July 2014 at 00:38:14 UTC, Dicebot wrote:

 All pages seem to miss all examples - simply not implemented 
 yet or oversight?


ah, nevermind:


 I still haven't included syntax highlighting. This really isn't
 hard, I just haven't gotten around to doing it yet.





 Jul 26 2014



prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Sat, Jul 26, 2014 at 10:54:12PM +0000, w0rp via Digitalmars-d wrote:

 http://w0rp.com:8010/library/index.html
 
 I just updated the site hosted there with the work I've done on
 integrating the library documentation to date. I spent a lot of time
 staring at the pages for a while trying to figure out how to fit
 everything on a page decent. I admit to hacking the std.algoritm
 tables into not being tables, etc. I would very much appreciate any
 pull requests which improve on what I've done so far with it. It's all
 on GitHub in the usual place.


What do you think about using tables for the functions under each
category (e.g. under "searching" in std.algorithm)? Currently it looks
like a random scattering of words, and it's quite confusing to look for
a particular symbol. A left-justified multi-column layout would be much
better IMHO.



 https://github.com/w0rp/new-dlang.org


[...]

I'll keep that in mind for when I have a bit more time; currently I'm
rather swamped and probably won't have time to submit PRs.


T

-- 
Computers aren't intelligent; they only think they are.



 Jul 26 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 27 July 2014 at 00:43:41 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Sat, Jul 26, 2014 at 10:54:12PM +0000, w0rp via 
 Digitalmars-d wrote:

 http://w0rp.com:8010/library/index.html
 
 I just updated the site hosted there with the work I've done on
 integrating the library documentation to date. I spent a lot 
 of time
 staring at the pages for a while trying to figure out how to 
 fit
 everything on a page decent. I admit to hacking the 
 std.algoritm
 tables into not being tables, etc. I would very much 
 appreciate any
 pull requests which improve on what I've done so far with it. 
 It's all
 on GitHub in the usual place.


 What do you think about using tables for the functions under 
 each
 category (e.g. under "searching" in std.algorithm)? Currently 
 it looks
 like a random scattering of words, and it's quite confusing to 
 look for
 a particular symbol. A left-justified multi-column layout would 
 be much
 better IMHO.


The std.algortihm documentation doesn't look good, and I don't 
have any good ideas for it.



 Jul 26 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/26/14, 6:30 PM, w0rp wrote:

 The std.algortihm documentation doesn't look good, and I don't have any
 good ideas for it.


I find std.algorithm among the best documented libraries out there! I 
must be in denial... -- Andrei



 Jul 26 2014



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 7/26/14, 6:30 PM, w0rp wrote:

The std.algortihm documentation doesn't look good, and I don't have
any good ideas for it.


 
 I find std.algorithm among the best documented libraries out there! I
 must be in denial... -- Andrei


"No, I'm not in denial! It can't be!!!"


:-P

-- 
Живёшь только однажды.



 Jul 26 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/26/14, 8:47 PM, H. S. Teoh via Digitalmars-d wrote:

 On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:

 On 7/26/14, 6:30 PM, w0rp wrote:

 The std.algortihm documentation doesn't look good, and I don't have
 any good ideas for it.


 I find std.algorithm among the best documented libraries out there! I
 must be in denial... -- Andrei


 "No, I'm not in denial! It can't be!!!"


Well correction: I think it's among the better documented modules in 
std. -- Andrei



 Jul 26 2014



 next sibling parent reply "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 27 July 2014 at 06:10:09 UTC, Andrei Alexandrescu 
wrote:

 On 7/26/14, 8:47 PM, H. S. Teoh via Digitalmars-d wrote:

 On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 7/26/14, 6:30 PM, w0rp wrote:

 The std.algortihm documentation doesn't look good, and I 
 don't have
 any good ideas for it.


 I find std.algorithm among the best documented libraries out 
 there! I
 must be in denial... -- Andrei


 "No, I'm not in denial! It can't be!!!"


 Well correction: I think it's among the better documented 
 modules in std. -- Andrei


It's not the text, it's just the current formatting. The cheat 
sheet can't fit into a smaller column size as a table. So you can 
break that down into smaller headings and paragraphs instead so 
it will reflow, but then the length of the page gets bumped up 
quite a bit and makes it harder to find things at a glance.

Because it's probably the most important library in all of 
Phobos, it's probably worth excluding the usual output of lists 
of Functions, Structs, etc. from std.algortihm and letting the 
cheat sheet itself be the list of symbols, which is organised a 
lot better than a sort by symbol type then name will ever be. I 
like the "these are for iteration" kind of categorisation. I'd 
probably then remove the table right at the top, so you have the 
module description and example above the fold.

That's what I'm thinking at the moment anyway.



 Jul 27 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Sunday, 27 July 2014 at 13:30:18 UTC, w0rp wrote:

 It's not the text, it's just the current formatting. The cheat 
 sheet can't fit into a smaller column size as a table. So you 
 can break that down into smaller headings and paragraphs 
 instead so it will reflow, but then the length of the page gets 
 bumped up quite a bit and makes it harder to find things at a 
 glance.

 Because it's probably the most important library in all of 
 Phobos, it's probably worth excluding the usual output of lists 
 of Functions, Structs, etc. from std.algortihm and letting the 
 cheat sheet itself be the list of symbols, which is organised a 
 lot better than a sort by symbol type then name will ever be. I 
 like the "these are for iteration" kind of categorisation. I'd 
 probably then remove the table right at the top, so you have 
 the module description and example above the fold.

 That's what I'm thinking at the moment anyway.


This is completely the wrong way to design anything. The design 
needs rework if it can't handle the content. You don't shorten 
the content to fit your design!

Also the main content area is far too narrow. The current design 
look ridiculous on a large monitor.

Desktop: http://imgur.com/Xr25TJ8

and because the design is fixed and not responsive in *any* way 
it also looks dire on mobile devices.

iPhone: http://imgur.com/fHduaH7

This is a poor amateurish design and i wish you would stop right 
now. If this ever goes live not only will all developers be 
extremely frustrated trying to actually read the documentation 
but we as a community are going to be laughing stock of the 
programming world!

This needs the attention of a professional designer and web 
developer.



 Jul 27 2014



 next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 27.07.2014 16:55, schrieb Gary Willoughby:

 This is a poor amateurish design and i wish you would stop right now. If
 this ever goes live not only will all developers be extremely frustrated
 trying to actually read the documentation but we as a community are
 going to be laughing stock of the programming world!

 This needs the attention of a professional designer and web developer.


I really wish you'd stop with this destructive attitude. Yes, the web 
design part is not ready for prime time, but it's definitely a big step 
forward already in many aspects, IMO.

Why don't you contribute some concrete CSS improvements, alternative 
design drafts, or at least suggestions instead of continuously trying to 
choke off all efforts? After all, the whole project is a community 
effort and I'm pretty sure that w0rp would happily accept some support.

Another thing is that most of the things done so far, as far as I 
understand, haven't been about the design or implementation thereof, but 
about the technical/content side.



 Jul 27 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Sunday, 27 July 2014 at 16:59:15 UTC, Sönke Ludwig wrote:

 I really wish you'd stop with this destructive attitude. Yes, 
 the web design part is not ready for prime time, but it's 
 definitely a big step forward already in many aspects, IMO.


Since when is the truth destructive?



 Jul 28 2014



  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 28.07.2014 09:18, schrieb Gary Willoughby:

 On Sunday, 27 July 2014 at 16:59:15 UTC, Sönke Ludwig wrote:

 I really wish you'd stop with this destructive attitude. Yes, the web
 design part is not ready for prime time, but it's definitely a big
 step forward already in many aspects, IMO.


 Since when is the truth destructive?


"completely the wrong way to design anything.", "current design look 
ridiculous", "poor amateurish design", "i wish you would stop right now" 
- all of those comments look pretty destructive to me. Truth or not 
doesn't have to have anything to do with being destructive or 
constructive. Most of the time there is a good truth and a bad truth and 
just focusing on the bad side can be pretty destructive.

What I'd wish for would be something like s/i wish you would stop right 
now/i'd suggest to .../g - or maybe pledge for a professional web 
designer? Just something that brings us forward instead of just 
promoting stagnancy.



 Jul 28 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:

 "completely the wrong way to design anything.", "current design 
 look ridiculous", "poor amateurish design", "i wish you would 
 stop right now" - all of those comments look pretty destructive 
 to me.


No, that's the truth! You can sugar coat it all you want but at
the end of the day you have to be blunt and honest if you want
professional results.

I did in fact start conversing with w0rp in a more congenial
manner but his childish attitude was when i decided to stop
pulling punches. My first comment was to suggest some javascript
libraries which was ignored. Then i pleaded with w0rp to use the
correct logo and colors. Which was then dismissed as he thought
*his* logo was better than the official one.

See the first reply in this post in which i outlined my position:

http://forum.dlang.org/thread/txdzebqxljlvjremintv forum.dlang.org

and tell me again who is being destructive. In that same thread
Walter is quoted as saying: "All excellent points, and I agree
with you on all of them. And I like the current logo, and want to
keep it." and yet w0rp still insists on going forward with this
terrible design.


 Truth or not doesn't have to have anything to do with being 
 destructive or constructive. Most of the time there is a good 
 truth and a bad truth and just focusing on the bad side can be 
 pretty destructive.


You're joking right? Anyone can see it's terrible and needs to be
done better. There are no versions of truth!


 What I'd wish for would be something like s/i wish you would 
 stop right now/i'd suggest to .../g - or maybe pledge for a 
 professional web designer? Just something that brings us 
 forward instead of just promoting stagnancy.


I tried but was immediately dismissed.



 Jul 28 2014



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/28/14, 10:25 AM, Gary Willoughby wrote:

 On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:

 "completely the wrong way to design anything.", "current design look
 ridiculous", "poor amateurish design", "i wish you would stop right
 now" - all of those comments look pretty destructive to me.


 No, that's the truth! You can sugar coat it all you want but at
 the end of the day you have to be blunt and honest if you want
 professional results.


No, if you want professional results you have to do professional work.

Andrei



 Jul 28 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 28 July 2014 at 18:13:50 UTC, Andrei Alexandrescu 
wrote:

 On 7/28/14, 10:25 AM, Gary Willoughby wrote:

 On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:

 "completely the wrong way to design anything.", "current 
 design look
 ridiculous", "poor amateurish design", "i wish you would stop 
 right
 now" - all of those comments look pretty destructive to me.


 No, that's the truth! You can sugar coat it all you want but at
 the end of the day you have to be blunt and honest if you want
 professional results.


 No, if you want professional results you have to do 
 professional work.

 Andrei


Of course, but you have to be honest when things are not going 
well!

On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote:

 Also, and this needs to be stressed, the major part of w0rp's 
 work so far is about the technical basis. You dismissed that as 
 a minor detail, but it is not.


The design is *the* most important part of the web site. Period! 
No one cares how it works, only the user experience of the site 
matters. Do you think users give a hoot how facebook works?

Yes someone does have to do the 'technical stuff' behind the 
scenes. I do it on a daily basis but users don't care about the 
backend. Even if the case was made that *this* site is for 
engineers, the design will do. Well, systems engineers are 

must make this site as accessible for everyone. We need to 'sell' 
D, not make it look amateurish.

In andreis Quo vadis talk i found it inspiring that he said in 
order to be considered a player we need to start acting like a 
player (paraphrasing). We need to start upping our game at this 
stuff!

The whole reason for this site's existence is to 'sell' D as much 
as possible _including_ being used as a repository of knowledge. 
It will sell better if the design is good, easy on the eye and 
easy to find what you need. The w0rp design is none of those, 
stop pretending it is.

Also who starts a project without designing it first? I mean 
honestly, why start such a major piece of work without even a 
vague spec? Has w0rp even asked users here what the site needs to 
encompass? Has the question been asked what content must exist, 
who needs what info and where, colour schemes, for mobile 
devices?  etc.

</flogging dead horse>



 Jul 28 2014



 next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 28.07.2014 21:13, schrieb Gary Willoughby:

 On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote:

 Also, and this needs to be stressed, the major part of w0rp's work so
 far is about the technical basis. You dismissed that as a minor
 detail, but it is not.


 The design is *the* most important part of the web site. Period! No one
 cares how it works, only the user experience of the site matters. Do you
 think users give a hoot how facebook works?


Yes, I don't try to argue against the importance of the design. The 
point is that it's an orthogonal feature and that it can be worked on 
mostly independently. You focus on the design and w0rp mostly focuses on 
the technical side, which is probably part of the reason why the 
discussion doesn't work out very well.


 Also who starts a project without designing it first? I mean honestly,
 why start such a major piece of work without even a vague spec? Has w0rp
 even asked users here what the site needs to encompass? Has the question
 been asked what content must exist, who needs what info and where,
 colour schemes, for mobile devices?  etc.

 </flogging dead horse>


He basically just took the mockup of Aleksandar Ruzicic, which was met 
with some optimism, and brought it to live. AFAICS that's all he really 
did WRT the design. The content was basically meant to stay the same as 
it is now*.

* Honestly, apart from some important key parts, such as the front page 
or the download page, it would be insane to start over and redo the 
contents, just for the sheer amount of work that this would mean.



 Jul 28 2014



  parent  "w0rp" <devw0rp gmail.com>  writes:


On Monday, 28 July 2014 at 19:31:24 UTC, Sönke Ludwig wrote:

 Am 28.07.2014 21:13, schrieb Gary Willoughby:

 On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote:

 Also, and this needs to be stressed, the major part of w0rp's 
 work so
 far is about the technical basis. You dismissed that as a 
 minor
 detail, but it is not.


 The design is *the* most important part of the web site. 
 Period! No one
 cares how it works, only the user experience of the site 
 matters. Do you
 think users give a hoot how facebook works?


 Yes, I don't try to argue against the importance of the design. 
 The point is that it's an orthogonal feature and that it can be 
 worked on mostly independently. You focus on the design and 
 w0rp mostly focuses on the technical side, which is probably 
 part of the reason why the discussion doesn't work out very 
 well.


 Also who starts a project without designing it first? I mean 
 honestly,
 why start such a major piece of work without even a vague 
 spec? Has w0rp
 even asked users here what the site needs to encompass? Has 
 the question
 been asked what content must exist, who needs what info and 
 where,
 colour schemes, for mobile devices?  etc.

 </flogging dead horse>


 He basically just took the mockup of Aleksandar Ruzicic, which 
 was met with some optimism, and brought it to live. AFAICS 
 that's all he really did WRT the design. The content was 
 basically meant to stay the same as it is now*.

 * Honestly, apart from some important key parts, such as the 
 front page or the download page, it would be insane to start 
 over and redo the contents, just for the sheer amount of work 
 that this would mean.


I'm not a designer. I'm a web developer. My understanding of web 
design only comes from a technical and UX point of view. How CSS 
works, how to structure forms to make them easier to read, etc. I 
would love to get some help from a designer. It is as you say. I 
brought Aleksandar's design to life, and that's pretty much how I 
work during the day. I work with designers who provide mock-ups, 
maybe some CSS, and I make it work.

I respect Gary's opinion that you should work on design first 
then the technical aspects, but I believe you can work either 
way, probably both ways simultaneously, and achieve the same 
result. Architecture and design cannot function without one 
another. Because I have far more experience as a web developer, 
I've put the vast majority of my focus on putting the site 
together so all of the pages fit into place, because they aren't 
going to change a great deal from how they are now in terms of 
content.

When it comes to web design, I just fill in the blanks when 
there's no-one else to help. It's amateur work because I'm not 
trained as a designer. So I'm just working on what I know I can 
eventually get right until someone with more design experience 
who is willing to submit pull requests comes along.



 Jul 28 2014



prev sibling next sibling parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/28/14, 12:13 PM, Gary Willoughby wrote:

 On Monday, 28 July 2014 at 18:13:50 UTC, Andrei Alexandrescu wrote:

 On 7/28/14, 10:25 AM, Gary Willoughby wrote:

 On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:

 "completely the wrong way to design anything.", "current design look
 ridiculous", "poor amateurish design", "i wish you would stop right
 now" - all of those comments look pretty destructive to me.


 No, that's the truth! You can sugar coat it all you want but at
 the end of the day you have to be blunt and honest if you want
 professional results.


 No, if you want professional results you have to do professional work.

 Andrei


 Of course, but you have to be honest when things are not going well!


Being honest does not entail being a jerk. -- Andrei

(edited)



 Jul 28 2014



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Monday, 28 July 2014 at 19:13:12 UTC, Gary Willoughby wrote:

 Also who starts a project without designing it first? I mean 
 honestly, why start such a major piece of work without even a 
 vague spec? Has w0rp even asked users here what the site needs 
 to encompass? Has the question been asked what content must 
 exist, who needs what info and where, colour schemes, for 
 mobile devices?  etc.


Current web site has certain purely technical issues that 
switching to more dynamic vibe.d based implementation will help 
to deal with. Even if design doesn't change a single bit it is a 
welcome and much needed change. Because of that starting with 
technical stuff makes perfect sense.

Stuff you care about is marketing stuff. It is only partially 
relevant to informational usability concerns that are of primary 
interest to existing language users.



 Jul 29 2014



prev sibling  parent  "Kagamin" <spam here.lot>  writes:


On Monday, 28 July 2014 at 19:13:12 UTC, Gary Willoughby wrote:

 Do you think users give a hoot how facebook works?


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


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


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



 Jul 29 2014



prev sibling  parent  =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 28.07.2014 19:25, schrieb Gary Willoughby:

 On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:

 "completely the wrong way to design anything.", "current design look
 ridiculous", "poor amateurish design", "i wish you would stop right
 now" - all of those comments look pretty destructive to me.


 No, that's the truth! You can sugar coat it all you want but at
 the end of the day you have to be blunt and honest if you want
 professional results.


That may be the case in a professional setting where everyone is payed 
to do the work. But in a community of volunteers this probably just 
leads to no results at all, because everyone involved gets discouraged. 
I'm not talking about sugar coating things, but about constructive 
criticism, suggesting improvements in addition to pointing out what is bad.


 I did in fact start conversing with w0rp in a more congenial
 manner but his childish attitude was when i decided to stop
 pulling punches. My first comment was to suggest some javascript
 libraries which was ignored. Then i pleaded with w0rp to use the
 correct logo and colors. Which was then dismissed as he thought
 *his* logo was better than the official one.


My perception was that he stated that his logo was just a placeholder 
and that someone would still have to get it right. The colors, as far as 
I can see, match the original logo pretty well, even though there are 
less highlights.


 See the first reply in this post in which i outlined my position:

 http://forum.dlang.org/thread/txdzebqxljlvjremintv forum.dlang.org

 and tell me again who is being destructive. In that same thread
 Walter is quoted as saying: "All excellent points, and I agree
 with you on all of them. And I like the current logo, and want to
 keep it." and yet w0rp still insists on going forward with this
 terrible design.


There have been quite some different opinions on the logo topic, and 
personally I think that removing the "button" border is absolutely fine, 
while shape and color are important not to alter without very good 
reason. My understanding was that w0rp was basically intending to just 
flattening the logo, although I see that changing the shape has also 
been part of the discussion. My perception also was that Walter 
understood that the logo was to be completely changed instead of just 
flattened, but I may be completely wrong, of course.

Anyway what's far worse is that the licensing situation of the current 
logo isn't clear and worst case it could mean that we'd have to switch 
the logo. But sorry, this is getting off topic.


 Truth or not doesn't have to have anything to do with being
 destructive or constructive. Most of the time there is a good truth
 and a bad truth and just focusing on the bad side can be pretty
 destructive.


 You're joking right? Anyone can see it's terrible and needs to be
 done better. There are no versions of truth!


I'm not joking. There are some substantial improvements regarding the 
global page navigation. The planned search feature would also be a big 
improvement. The rest of the page is currently modeled after the mockup 
that got posted by the OP and really hasn't been subject to any deeper 
thoughts so far.

This is what I mean with the positive truth, and what just bothered me 
is when you started to completely dismiss the whole project as bad. I 
just don't like talking in purely black and white, because reality 
almost never is.

Also, and this needs to be stressed, the major part of w0rp's work so 
far is about the technical basis. You dismissed that as a minor detail, 
but it is not. It's a part of the whole thing that also needs to get 
done and someone has to do it. The good thing is that it is - with the 
help of good semantic HTML and good use of CSS - mostly independent of 
the site layout and styling.


 What I'd wish for would be something like s/i wish you would stop
 right now/i'd suggest to .../g - or maybe pledge for a professional
 web designer? Just something that brings us forward instead of just
 promoting stagnancy.


 I tried but was immediately dismissed.


I think that the discussion just too quickly went into an all or nothing 
argument, which is always difficult to resolve. And I guess this was 
also at least part of the reason why you stopped with suggestions and 
why w0rp possibly has troubles accepting valid criticism from you...

Anyway, what about making some quick mockups or design rules that could 
be used as a basis for a more principled approach? But I have to admit 
that this forum is not the ideal place to work on something like this. 
We need a much more structured approach to answer questions such as the 
ones Ola posted. Maybe using a separate newsgroup or mailing list + the 
wiki.



 Jul 28 2014



prev sibling  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 27 July 2014 at 14:55:59 UTC, Gary Willoughby wrote:

 On Sunday, 27 July 2014 at 13:30:18 UTC, w0rp wrote:

 It's not the text, it's just the current formatting. The cheat 
 sheet can't fit into a smaller column size as a table. So you 
 can break that down into smaller headings and paragraphs 
 instead so it will reflow, but then the length of the page 
 gets bumped up quite a bit and makes it harder to find things 
 at a glance.

 Because it's probably the most important library in all of 
 Phobos, it's probably worth excluding the usual output of 
 lists of Functions, Structs, etc. from std.algortihm and 
 letting the cheat sheet itself be the list of symbols, which 
 is organised a lot better than a sort by symbol type then name 
 will ever be. I like the "these are for iteration" kind of 
 categorisation. I'd probably then remove the table right at 
 the top, so you have the module description and example above 
 the fold.

 That's what I'm thinking at the moment anyway.


 This is completely the wrong way to design anything. The design 
 needs rework if it can't handle the content. You don't shorten 
 the content to fit your design!

 Also the main content area is far too narrow. The current 
 design look ridiculous on a large monitor.

 Desktop: http://imgur.com/Xr25TJ8

 and because the design is fixed and not responsive in *any* way 
 it also looks dire on mobile devices.

 iPhone: http://imgur.com/fHduaH7

 This is a poor amateurish design and i wish you would stop 
 right now. If this ever goes live not only will all developers 
 be extremely frustrated trying to actually read the 
 documentation but we as a community are going to be laughing 
 stock of the programming world!

 This needs the attention of a professional designer and web 
 developer.


If you would like to contribute to the project, I am more than 
happy to accept pull requests. I wouldn't try to judge too 
harshly based on what you can see at the moment, as this project 
is very much a work in progress. The majority of the work I've 
been doing at the moment has just been technical to fit 
everything into place.

If you are going to post screenshots of a design to criticise it, 
I ask that you at least take the time to post accurate 
screenshots. Whatever methods of resizing your browser window you 
used completely failed to trigger the media queries which take 
columns away as the screen size is reduced, as can be seen here.

https://imgur.com/dlSzuKo,6REhZng

The documentation doesn't fit so well into the screen size of the 
original iPhone, which is 320 pixels wide, but easily fits into 
screen sizes of the iPhone4 and above, which is 640 pixels and 
above. I have been taking the time to edit code samples and test 
against smaller screen sizes so the content fits comfortably.

You absolutely must change your content to fit it into smaller 
screens. You cannot send a massive cargo plane to an airfield 
which doesn't have large enough runways. You send smaller planes 
to carry your freight to that airport. If you have a table where 
the length of a symbol expands a single column too wide to fit 
the second column's content on a phone screen comfortably, you 
have to at the very least not use a table on the phone screens.

Regarding display at very large widths. that is something which 
can be adjusted later. It's far easier to focus on fitting 
content into smaller screen sizes first and then build outwards, 
than it is to design everything for large screen sizes first and 
then compact inwards. You can always expand column widths and 
provide more non-essential but supllemental content afterwards so 
the space is used effectively.

That said, there should be an upper limit, where beyond a given 
width expanding to fill it entirely would not be a good idea. You 
are always contrained by an upper limit on how long a line of 
text should be. This doesn't have to be as small as 80 or 90 
characters, as there are some studies which show that somewhere 
as high as 100 or 110 characters per line can be read effectively.

Again, if you would like to contribute something of value, please 
do not hesitate to do so.



 Jul 27 2014



 next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Sun, Jul 27, 2014 at 08:43:48PM +0000, w0rp via Digitalmars-d wrote:
[...]

 You absolutely must change your content to fit it into smaller
 screens. You cannot send a massive cargo plane to an airfield which
 doesn't have large enough runways. You send smaller planes to carry
 your freight to that airport. If you have a table where the length of
 a symbol expands a single column too wide to fit the second column's
 content on a phone screen comfortably, you have to at the very least
 not use a table on the phone screens.


I'm not a professional web developer, but isn't the current convention
to deliver two different CSS files for desktop vs. mobile browsers? I'm
not sure if it's a good idea to shoehorn a single design to fit two
vastly different display sizes and usage constraints.


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!



 Jul 27 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 27 July 2014 at 23:38:44 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 On Sun, Jul 27, 2014 at 08:43:48PM +0000, w0rp via 
 Digitalmars-d wrote:
 [...]

 You absolutely must change your content to fit it into smaller
 screens. You cannot send a massive cargo plane to an airfield 
 which
 doesn't have large enough runways. You send smaller planes to 
 carry
 your freight to that airport. If you have a table where the 
 length of
 a symbol expands a single column too wide to fit the second 
 column's
 content on a phone screen comfortably, you have to at the very 
 least
 not use a table on the phone screens.


 I'm not a professional web developer, but isn't the current 
 convention
 to deliver two different CSS files for desktop vs. mobile 
 browsers? I'm
 not sure if it's a good idea to shoehorn a single design to fit 
 two
 vastly different display sizes and usage constraints.


 T


To display more appropriate content for two different screen 
sizes, you use CSS media queries to change the layout, which 
typically just test the screen width. You can break this down 
into separate files if you place the media queries on the 'link' 
tag elements, or inside the CSS files if you use the media query 
syntax in there. One option in a few cases is to show one element 
at larger screen sizes, and another element at smaller screen 
sizes. So you could use a table when there is more available 
screen width, or sections and paragraphs when there is less 
available screenw width. More commonly you will attempt use the 
same elements for both, and reposition the subelements in a 
similar manner.



 Jul 27 2014



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 28 July 2014 at 06:54:00 UTC, w0rp wrote:

 media query syntax in there. One option in a few cases is to 
 show one element at larger screen sizes, and another element at 
 smaller screen sizes.


I think you should represent the information once. Otherwise 
people using assistive technologies might run into problems.


 So you could use a table when there is more available screen 
 width, or sections and paragraphs when there is less available 
 screenw width.


It is unlikely that people will spend a lot of time reading 
tables on devices smaller than a tablet.

HTML allows the browser to break up tables. Tables are not meant 
to be used for layout.

Even if browsers don't provide table optimized views, I'd suggest 
sticking to semantic HTML rather than trying to implement fixes 
for browsers not doing a good job. That might change in the 
future.

Sure you can create a layout that will work fluidly with all 
screen sizes without using javascript, but it takes extra work 
when you create content. That extra work is probably better spent 
creating a better experience for desktop use which is the primary 
use scenario.


 More commonly you will attempt use the same elements for both, 
 and reposition the subelements in a similar manner.


Yeah, but in reality you will often have to resort to javascript 
or spend >100% more time on the layout structure, to make it work 
on all screen sizes with just CSS (for a design that is a bit 
more complicated than a book).

CSS is less powerful than XSL/XSLT, so if you want multiple 
layouts maybe consider XSLT on the server instead.

Having the documentation in XML and mapping it to HTML using XSLT 
has many advantages (such as generating PDF).



 Jul 28 2014



  parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 28 July 2014 at 07:51:51 UTC, Ola Fosheim Grøstad 
wrote:

 I think you should represent the information once. Otherwise 
 people using assistive technologies might run into problems.


(You might also run into SEO problems, getting a reduced ranking 
in search engines, if you make lots of text invisible.)



 Jul 28 2014



prev sibling  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Sunday, 27 July 2014 at 20:43:49 UTC, w0rp wrote:

 You absolutely must change your content to fit it into smaller 
 screens. You cannot send a massive cargo plane to an airfield 
 which doesn't have large enough runways. You send smaller 
 planes to carry your freight to that airport. If you have a 
 table where the length of a symbol expands a single column too 
 wide to fit the second column's content on a phone screen 
 comfortably, you have to at the very least not use a table on 
 the phone screens.


This is total nonsense.


 Regarding display at very large widths. that is something which 
 can be adjusted later. It's far easier to focus on fitting 
 content into smaller screen sizes first and then build 
 outwards, than it is to design everything for large screen 
 sizes first and then compact inwards. You can always expand 
 column widths and provide more non-essential but supllemental 
 content afterwards so the space is used effectively.


No, the current design is too small, period. Everything about it 
is too small. The fonts, the column widths, the logo, etc. 
Screens are getting bigger and screen resolutions are increasing. 
Even tablets have 1080p+ resolutions.


 That said, there should be an upper limit, where beyond a given 
 width expanding to fill it entirely would not be a good idea. 
 You are always contrained by an upper limit on how long a line 
 of text should be. This doesn't have to be as small as 80 or 90 
 characters, as there are some studies which show that somewhere 
 as high as 100 or 110 characters per line can be read 
 effectively.


Agreed but you are way below that sweet spot.


 Again, if you would like to contribute something of value, 
 please do not hesitate to do so.


I am contributing but you are completely ignoring me and 
attacking what i'm saying. I've been a professional web 
application developer for years and have a lot of experience with 
design and UX. Everybody here is completely ignoring that fact! 
You don't even understand branding. So what's the point of me 
trying to contribute?



 Jul 28 2014



 next sibling parent reply "w0rp" <devw0rp gmail.com>  writes:


On Monday, 28 July 2014 at 07:29:48 UTC, Gary Willoughby wrote:

 On Sunday, 27 July 2014 at 20:43:49 UTC, w0rp wrote:

 You absolutely must change your content to fit it into smaller 
 screens. You cannot send a massive cargo plane to an airfield 
 which doesn't have large enough runways. You send smaller 
 planes to carry your freight to that airport. If you have a 
 table where the length of a symbol expands a single column too 
 wide to fit the second column's content on a phone screen 
 comfortably, you have to at the very least not use a table on 
 the phone screens.


 This is total nonsense.


You wouldn't fit a very large page of sample code on a slide if
you wanted to show an example at a presentation, unless your
point was to show how bad it is to write too much code. You have
to write your sample such that it fits on the slide, so you will
remove braces you might otherwise use religiously, etc. It's not
total nonsense, it's common sense.


 Regarding display at very large widths. that is something 
 which can be adjusted later. It's far easier to focus on 
 fitting content into smaller screen sizes first and then build 
 outwards, than it is to design everything for large screen 
 sizes first and then compact inwards. You can always expand 
 column widths and provide more non-essential but supllemental 
 content afterwards so the space is used effectively.


 No, the current design is too small, period. Everything about 
 it is too small. The fonts, the column widths, the logo, etc. 
 Screens are getting bigger and screen resolutions are 
 increasing. Even tablets have 1080p+ resolutions.


I just explained that I was working with smaller screens and
working upwards, because it's a far more effective way to design
for all devices. This is why elements on the page currently fit
smaller screens better. I haven't taken the time to make
effective use of space for larger screen sizes yet. I'm well
aware of the 1080p resolution, because the layout fits well on a
1080p screen. The upper limit on screen widths I have worked for
so far is 1200 pixels, and slightly above that, which follows the
Bootstrap screen sizes.


 That said, there should be an upper limit, where beyond a 
 given width expanding to fill it entirely would not be a good 
 idea. You are always contrained by an upper limit on how long 
 a line of text should be. This doesn't have to be as small as 
 80 or 90 characters, as there are some studies which show that 
 somewhere as high as 100 or 110 characters per line can be 
 read effectively.


 Agreed but you are way below that sweet spot.


That is not true. The largest screen width accommodates about 95
CPL for paragraphs.


 Again, if you would like to contribute something of value, 
 please do not hesitate to do so.


 I am contributing but you are completely ignoring me and 
 attacking what i'm saying. I've been a professional web 
 application developer for years and have a lot of experience 
 with design and UX. Everybody here is completely ignoring that 
 fact! You don't even understand branding. So what's the point 
 of me trying to contribute?


Your comments are being ignored because your comments have been
nothing short of a personal attack on myself. If you wish to make
a serious contribution to a project, you should learn to use more
tact, and speak to objective points of argument. A meaningful
contribution would consist of contributing art assets, writing
CSS, drafting mock-ups for improvements, etc. Thus far, you have
failed to do any of this.



 Jul 28 2014



  parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 28 July 2014 at 08:30:05 UTC, w0rp wrote:

 Your comments are being ignored because your comments have been
 nothing short of a personal attack on myself. If you wish to 
 make
 a serious contribution to a project, you should learn to use 
 more
 tact, and speak to objective points of argument. A meaningful
 contribution would consist of contributing art assets, writing
 CSS, drafting mock-ups for improvements, etc. Thus far, you have
 failed to do any of this.


I'm speaking the truth which often hurts.

Your problem is you are not able to take any criticism whatsoever 
against this piece of work. The design is awful, period.

I have nothing against you personally and i think it's good that 
you are initiating this effort but the design is the first thing 
that should be addressed and in no way be an afterthought. I 
apologise if i sound terse but usually in my line of work shoddy 
efforts have to be address upfront and with prejudice.

The very first thing you should of done is to create mockups (in 
photoshop, etc) of what each page should look like and make sure 
the design can accommodate all the content. Once the design is 
approved then implement the site. The backend is inconsequential, 
use whatever you are comfortable with. Vibe.d, LAMP it doesn't 
matter. Users don't care about the backend. What matters is the 
user experience (especially within the documentation) and that is 
what should be addressed in a thoughtful professional matter. 
This is not optional or something that should be done along the 
way.



 Jul 28 2014



 next sibling parent  "uri" <email ether.com>  writes:


On Monday, 28 July 2014 at 09:16:44 UTC, Gary Willoughby wrote:

You said you don't like it and you were heard the first time


 I'm speaking the truth which often hurts.


Yes and I don't see w0rp running off and sulking about it either.


 Your problem is you are not able to take any criticism 
 whatsoever against this piece of work. The design is awful, 
 period.

 I have nothing against you personally and i think it's good 
 that you are initiating this effort but the design is the first 
 thing that should be addressed and in no way be an 
 afterthought. I apologise if i sound terse but usually in my 
 line of work shoddy efforts have to be address upfront and with 
 prejudice.


w0rp et. al. have asked for your contributions in art/design 
because you say you know how to do a better job.


 The very first thing you should of done is to create mockups 
 (in photoshop, etc) of what each page should look like and make 
 sure the design can accommodate all the content. Once the 
 design is approved then implement the site. The backend is 
 inconsequential, use whatever you are comfortable with. Vibe.d, 
 LAMP it doesn't matter. Users don't care about the backend. 
 What matters is the user experience (especially within the 
 documentation) and that is what should be addressed in a 
 thoughtful professional matter. This is not optional or 
 something that should be done along the way.


Stating something is crap in a volunteer project is useless 
unless you can follow it up with something equally useful.

For an engineer you sound just like our marketing team at work: 
Always ready to produce some warm and fuzzy ideas but light on 
the specifics and actual work.

/uri



 Jul 28 2014



prev sibling  parent reply "Dicebot" <public dicebot.lv>  writes:


On Monday, 28 July 2014 at 09:16:44 UTC, Gary Willoughby wrote:

 Your problem is you are not able to take any criticism 
 whatsoever against this piece of work. The design is awful, 
 period.


Criticism is worthless if you are not ready to actually do 
something about it - providing detailed list of necessary changes 
at the very least. D development has always been about going and 
getting stuff done - same principle apply here. If you have 
professional web development experience that may help here - 
start helping somehow. Otherwise this criticism is just 
distraction.



 Jul 28 2014



  parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:

 going and getting stuff done - same principle apply here. If 
 you have professional web development experience that may help 
 here - start helping somehow.


You need to define and agree on a process first. If not you will 
have to redo the site 10 times before getting to the end result. 
Then you will have to redo it whenever someone decides to add a 
feature that contradicts the design/layout, because they assumed 
that it would be easy to add later.

What are the key requirements?

What is the primary user base (front page, doc pages etc)

What are the main target platforms?

What is the intermediate format?

What is the primary use scenarios?

What are the key future functionality that it has to accomodate?

What nice-to-haves can we cut in order to reduce work?

Who gets the final word when you cannot get a decision?

etc.



 Jul 28 2014



 next sibling parent  "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 28 July 2014 at 11:35:21 UTC, Ola Fosheim Grøstad
wrote:

 On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:

 going and getting stuff done - same principle apply here. If 
 you have professional web development experience that may help 
 here - start helping somehow.


 You need to define and agree on a process first. If not you 
 will have to redo the site 10 times before getting to the end 
 result. Then you will have to redo it whenever someone decides 
 to add a feature that contradicts the design/layout, because 
 they assumed that it would be easy to add later.

 What are the key requirements?

 What is the primary user base (front page, doc pages etc)

 What are the main target platforms?

 What is the intermediate format?

 What is the primary use scenarios?

 What are the key future functionality that it has to accomodate?

 What nice-to-haves can we cut in order to reduce work?

 Who gets the final word when you cannot get a decision?

 etc.


At last somebody else who understands.



 Jul 28 2014



prev sibling  parent  "Dicebot" <public dicebot.lv>  writes:


On Monday, 28 July 2014 at 11:35:21 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:

 going and getting stuff done - same principle apply here. If 
 you have professional web development experience that may help 
 here - start helping somehow.


 You need to define and agree on a process first. If not you 
 will have to redo the site 10 times before getting to the end 
 result. Then you will have to redo it whenever someone decides 
 to add a feature that contradicts the design/layout, because 
 they assumed that it would be easy to add later.

 What are the key requirements?

 What is the primary user base (front page, doc pages etc)

 What are the main target platforms?

 What is the intermediate format?

 What is the primary use scenarios?

 What are the key future functionality that it has to accomodate?

 What nice-to-haves can we cut in order to reduce work?

 Who gets the final word when you cannot get a decision?

 etc.


It has never worked that way with D development process and I 
don't see it happening without any major structural changes. 
Pretty much everything that does not come from Walter or Andrei 
is decentralized anarchy-driven development - you do something, 
show it to community, see results.

All these questions are nonsense crap without someone actually 
willing to do the work. Such attitude may insult professionals 
but there are no hired professionals working here.



 Jul 28 2014



prev sibling  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 7/28/14, 12:29 AM, Gary Willoughby wrote:

 I am contributing but you are completely ignoring me and attacking what
 i'm saying. I've been a professional web application developer for years
 and have a lot of experience with design and UX. Everybody here is
 completely ignoring that fact! You don't even understand branding. So
 what's the point of me trying to contribute?


I've been in similar situations in the past so I sympathize. The one 
thing I noticed gets the point across is to just do good work and just 
show it. People otherwise ignorant of what goes into a piece of work 
_can_ often appreciate a compelling end result.

Andrei



 Jul 28 2014



 next sibling parent reply "Gary Willoughby" <dev nomad.so>  writes:


On Monday, 28 July 2014 at 16:58:53 UTC, Andrei Alexandrescu 
wrote:

 On 7/28/14, 12:29 AM, Gary Willoughby wrote:

 I am contributing but you are completely ignoring me and 
 attacking what
 i'm saying. I've been a professional web application developer 
 for years
 and have a lot of experience with design and UX. Everybody 
 here is
 completely ignoring that fact! You don't even understand 
 branding. So
 what's the point of me trying to contribute?


 I've been in similar situations in the past so I sympathize. 
 The one thing I noticed gets the point across is to just do 
 good work and just show it. People otherwise ignorant of what 
 goes into a piece of work _can_ often appreciate a compelling 
 end result.

 Andrei


It is frustrating because i want this to be done well as it could 
really help D take off. If it's done poorly we will be the 
laughing stock especially as our immediate competition is other 
programming sites.

http://new-www.haskell.org/
https://www.python.org/
https://developer.apple.com/swift/
https://www.ruby-lang.org
http://www.perl.org/
https://www.dartlang.org/

If the new D site isn't at least as good as any of the above we 
have failed. I'm up to my eye balls in other projects at the 
minute so i can't contribute any code.



 Jul 28 2014



  parent  "Kagamin" <spam here.lot>  writes:


On Monday, 28 July 2014 at 17:23:37 UTC, Gary Willoughby wrote:

 It is frustrating because i want this to be done well as it 
 could really help D take off.


Doing it on LAMP won't help D to take off. In a sense, you don't 
even criticize this work, as a professional web designer, you can 
provide a constructive feedback, if you assess, whether the D web 
stack is ready for use by a web designer, whether SSI is done 
right, what features are missing or confusing, is it easy do 
setup a development environment. If LAMP is better, you can 
report the problems.


 https://www.dartlang.org/


Actually bad scrolling UX because of the floating panel.



 Jul 29 2014



prev sibling  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Mon, Jul 28, 2014 at 09:58:59AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 7/28/14, 12:29 AM, Gary Willoughby wrote:

I am contributing but you are completely ignoring me and attacking
what i'm saying. I've been a professional web application developer
for years and have a lot of experience with design and UX. Everybody
here is completely ignoring that fact! You don't even understand
branding. So what's the point of me trying to contribute?




Your hostile tone may have contributed to that reaction, however
justified your arguments may have been. Coming into a volunteer project
and telling people things like "this is garbage", "this is amateurish",
"you should stop", "you don't understand anything at all", is very
hostile, and therefore likely to provoke a negative reaction, even if
the work concerned actually *is* garbage, amateurish, etc..

As Andrei said (quoted below), if instead of tearing others'
(voluntary!) work into pieces, you produce a superior piece of work and
show it (even if it's just a concept sketch of the end result, not the
actual implementation), it will be much more convincing, and people will
be much more likely to listen to you. As they say, "show, don't tell".



 I've been in similar situations in the past so I sympathize. The one
 thing I noticed gets the point across is to just do good work and just
 show it.  People otherwise ignorant of what goes into a piece of work
 _can_ often appreciate a compelling end result.


[...]


T

-- 
Many open minds should be closed for repairs. -- K5 user



 Jul 28 2014



prev sibling  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 27 July 2014 at 06:10:09 UTC, Andrei Alexandrescu 
wrote:

 On 7/26/14, 8:47 PM, H. S. Teoh via Digitalmars-d wrote:

 On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 7/26/14, 6:30 PM, w0rp wrote:

 The std.algortihm documentation doesn't look good, and I 
 don't have
 any good ideas for it.


 I find std.algorithm among the best documented libraries out 
 there! I
 must be in denial... -- Andrei


 "No, I'm not in denial! It can't be!!!"


 Well correction: I think it's among the better documented 
 modules in std. -- Andrei


Still, all the documentation do not looks good.



 Aug 21 2014



prev sibling  parent  Timon Gehr <timon.gehr gmx.ch>  writes:


On 07/27/2014 04:39 AM, Andrei Alexandrescu wrote:

 On 7/26/14, 6:30 PM, w0rp wrote:

 The std.algortihm documentation doesn't look good, and I don't have any
 good ideas for it.


 I find std.algorithm among the best documented libraries out there! I


          ^~~~~~~~~~~~~~~~~~~

This actually tripped me up while speed-reading. :o) Intended?


 must be in denial... -- Andrei





 Jul 28 2014



prev sibling  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 27.07.2014 00:54, schrieb w0rp:

 http://w0rp.com:8010/library/index.html


Since the site is running with vibe.d anyway, I'd think about using 
registerApiDocs() instead of generating individual HTML files. This 
gives much nicer URLs and also avoids potential issues with file systems 
that are case insensitive. See http://vibed.org/api/ for an example.



 Jul 27 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Sunday, 27 July 2014 at 16:32:15 UTC, Sönke Ludwig wrote:

 Am 27.07.2014 00:54, schrieb w0rp:

 http://w0rp.com:8010/library/index.html


 Since the site is running with vibe.d anyway, I'd think about 
 using registerApiDocs() instead of generating individual HTML 
 files. This gives much nicer URLs and also avoids potential 
 issues with file systems that are case insensitive. See 
 http://vibed.org/api/ for an example.


I have just been playing with this during this evening by 
learning from the source for the vibed.org website. I managed to 
integrate serving the documentation pages from /library/ just 
fine. This is a definite improvement. Thank you for the 
suggestion. At the very, very least, the URLs are cleaner this 
way. If this is paired with some automatic recompliation of Diet 
templates too, then it could be much more convenient to work with.

I set up the ddoc macros by calling the setDefaultDdocMacroFiles 
and setOverrideDdocMacroFiles functions, which sets them in the 
global scope. This could be better, but I couldn't figure out if 
there was a way to provide the .ddoc macros to use per Package 
object or similar. This doesn't matter too much right now, but it 
might be nice in future to provide documentation for historical D 
language versions too in future, like on the vibe.d site.

You can see some running examples on the site now.

http://w0rp.com:8010/library/std.parallelism/

Obviously if it stays that way, some 301 redirects will have to 
be set up pointing from the old URLs to the new ones. I've been 
setting up a few as I go already.

I'll look at playing with the style of the documentation pages 
some more another evening. I've had a few ideas for improvements, 
and I obviously still need to include syntax highlighting. Is 
this the library which is being used on the live site now for 
that?

https://code.google.com/p/google-code-prettify/

I'd be happy to go with that for now, or whatever else if anyone 
has any better suggestions. I used hightlight.js on my personal 
site to some success, but I remember thinking that the 
highlighting could have been better with it a few times.

http://highlightjs.org/

That's all for now.



 Jul 28 2014



 next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 29.07.2014 00:04, schrieb w0rp:

 On Sunday, 27 July 2014 at 16:32:15 UTC, Sönke Ludwig wrote:

 Am 27.07.2014 00:54, schrieb w0rp:

 http://w0rp.com:8010/library/index.html


 Since the site is running with vibe.d anyway, I'd think about using
 registerApiDocs() instead of generating individual HTML files. This
 gives much nicer URLs and also avoids potential issues with file
 systems that are case insensitive. See http://vibed.org/api/ for an
 example.


 I have just been playing with this during this evening by learning from
 the source for the vibed.org website. I managed to integrate serving the
 documentation pages from /library/ just fine. This is a definite
 improvement. Thank you for the suggestion. At the very, very least, the
 URLs are cleaner this way. If this is paired with some automatic
 recompliation of Diet templates too, then it could be much more
 convenient to work with.

 I set up the ddoc macros by calling the setDefaultDdocMacroFiles and
 setOverrideDdocMacroFiles functions, which sets them in the global
 scope. This could be better, but I couldn't figure out if there was a
 way to provide the .ddoc macros to use per Package object or similar.
 This doesn't matter too much right now, but it might be nice in future
 to provide documentation for historical D language versions too in
 future, like on the vibe.d site.


The DocGroupContext class currently returns null for its 
overrideMacroDefinitions and defaultMacroDefinitions properties. This 
would just have to be extended so that it becomes possible to inject 
custom values. I've added a ticket for that:
https://github.com/rejectedsoftware/ddox/issues/51


 You can see some running examples on the site now.

 http://w0rp.com:8010/library/std.parallelism/

 Obviously if it stays that way, some 301 redirects will have to be set
 up pointing from the old URLs to the new ones. I've been setting up a
 few as I go already.


There is also a pending change for the current documentation that 
changes the current link style (balancedParens.html) to lowercase 
underscore notation (balanced_parens.html), so there will be a bunch of 
redirects already. One issue with this is that the new style will 
sometimes have ambiguous redirects to the canonical style 
(balancedParens) because it removes the case information, but I don't 
really see a way around that.


 I'll look at playing with the style of the documentation pages some more
 another evening. I've had a few ideas for improvements, and I obviously
 still need to include syntax highlighting. Is this the library which is
 being used on the live site now for that?

 https://code.google.com/p/google-code-prettify/


That plus some modifications to add D support. But my plan was to use 
server side highlighting using Brian Schott's lexer in the future.



 Jul 28 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:

 I'll look at playing with the style of the documentation pages 
 some more
 another evening. I've had a few ideas for improvements, and I 
 obviously
 still need to include syntax highlighting. Is this the library 
 which is
 being used on the live site now for that?

 https://code.google.com/p/google-code-prettify/


 That plus some modifications to add D support. But my plan was 
 to use server side highlighting using Brian Schott's lexer in 
 the future.


That's probably a good call. Were you thinking of discovering 
<code> blocks in pages and running the lexer on them to produce 
the formatted output?



 Jul 28 2014



 next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com>  writes:


Am 29.07.2014 00:54, schrieb w0rp:

 On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:

 I'll look at playing with the style of the documentation pages some more
 another evening. I've had a few ideas for improvements, and I obviously
 still need to include syntax highlighting. Is this the library which is
 being used on the live site now for that?

 https://code.google.com/p/google-code-prettify/


 That plus some modifications to add D support. But my plan was to use
 server side highlighting using Brian Schott's lexer in the future.


 That's probably a good call. Were you thinking of discovering <code>
 blocks in pages and running the lexer on them to produce the formatted
 output?


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



 Jul 29 2014



  parent reply "w0rp" <devw0rp gmail.com>  writes:


On Tuesday, 29 July 2014 at 08:27:40 UTC, Sönke Ludwig wrote:

 Am 29.07.2014 00:54, schrieb w0rp:

 On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:

 I'll look at playing with the style of the documentation 
 pages some more
 another evening. I've had a few ideas for improvements, and 
 I obviously
 still need to include syntax highlighting. Is this the 
 library which is
 being used on the live site now for that?

 https://code.google.com/p/google-code-prettify/


 That plus some modifications to add D support. But my plan 
 was to use
 server side highlighting using Brian Schott's lexer in the 
 future.


 That's probably a good call. Were you thinking of discovering 
 <code>
 blocks in pages and running the lexer on them to produce the 
 formatted
 output?


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


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



 Jul 29 2014



  parent  "Colin" <grogan.colin gmail.com>  writes:


On Tuesday, 29 July 2014 at 08:51:43 UTC, w0rp wrote:

 On Tuesday, 29 July 2014 at 08:27:40 UTC, Sönke Ludwig wrote:

 Am 29.07.2014 00:54, schrieb w0rp:

 On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:

 I'll look at playing with the style of the documentation 
 pages some more
 another evening. I've had a few ideas for improvements, and 
 I obviously
 still need to include syntax highlighting. Is this the 
 library which is
 being used on the live site now for that?

 https://code.google.com/p/google-code-prettify/


 That plus some modifications to add D support. But my plan 
 was to use
 server side highlighting using Brian Schott's lexer in the 
 future.


 That's probably a good call. Were you thinking of discovering 
 <code>
 blocks in pages and running the lexer on them to produce the 
 formatted
 output?


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


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


Confusing sentence. Deception at it's finest.

/sorry



 Jul 29 2014



prev sibling  parent reply "Anonymous" <a a.com>  writes:


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



 Jul 30 2014



  parent reply "Hubert" <rutgermegahertz gmail.com>  writes:


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

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

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

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

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



 Aug 20 2014



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:

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

 My emphasis has been on creating a friendly first impression; a 
 lightweight page to introduce newcomers to D and get them 
 started quickly.


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


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


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



 Aug 21 2014



prev sibling next sibling parent  Jacob Carlborg <doob me.com>  writes:


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


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


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

-- 
/Jacob Carlborg



 Aug 21 2014



prev sibling next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:

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

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

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

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

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


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



 Aug 21 2014



 next sibling parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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


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


exactly what i wanted to say, but cannot find the appropriate words!



 Aug 21 2014



prev sibling next sibling parent reply "Kagamin" <spam here.lot>  writes:


On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:

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


Hmm... I don't remember, when I last visited the front page, I 
don't even know, what it looks like. What one would need there 
and what productivity you plan to get there?



 Aug 21 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 21 August 2014 at 15:14:05 UTC, Kagamin wrote:

 On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:

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


 Hmm... I don't remember, when I last visited the front page, I 
 don't even know, what it looks like. What one would need there 
 and what productivity you plan to get there?


I check various parts of documentation (not DDOC-generates Phobos 
part but manually written articles) on a regular basis. It is 
often faster to find via navigating then search query because 
term usage is spread all across.



 Aug 21 2014



 next sibling parent  "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=  writes:


On Thursday, 21 August 2014 at 15:16:52 UTC, Dicebot wrote:

 I check various parts of documentation (not DDOC-generates 
 Phobos part but manually written articles) on a regular basis. 
 It is often faster to find via navigating then search query 
 because term usage is spread all across.


But you will get all that from the documentation subsection?

I do think the frontpage should indicate that D is a systems 
programming language, though. I also think code samples that 
highlight main language features constructs belong on the front 
page. It should try to quickly give an enticing answer to 
questions like these:

What is this D thing google sent me to?
What does it look like?
Is this project abandoned or active?
Where can I get a trouble free install?
What is the license?
Where is the newbie tutorial?
How active is the community/where are the forums?

The second level would be answers to questions like:
Where are the specs?
Benchmarks?
Academic papers?
Bugfix responsiveness?
Etc..



 Aug 21 2014



prev sibling  parent reply "Kagamin" <spam here.lot>  writes:


On Thursday, 21 August 2014 at 15:16:52 UTC, Dicebot wrote:

 On Thursday, 21 August 2014 at 15:14:05 UTC, Kagamin wrote:

 On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:

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


 Hmm... I don't remember, when I last visited the front page, I 
 don't even know, what it looks like. What one would need there 
 and what productivity you plan to get there?


 I check various parts of documentation (not DDOC-generates 
 Phobos part but manually written articles) on a regular basis. 
 It is often faster to find via navigating then search query 
 because term usage is spread all across.


Such things should be probably integrated in a documentation 
start page: language reference, library reference, articles, 
papers, wiki, howtos, books. There's too much to integrate into 
single navigation menu.



 Aug 24 2014



  parent reply "Hubert" <rutgermegahertz gmail.com>  writes:


Thanks for the response! I do agree that the colors are way too 
"hot" (I've must've been quite tired when I submitted that mockup)

Someone noted that the concept that I pitched had too much 
whitespace, which is a sentiment that I do not share. There's a 
lot of issues with the readability in the current design; way too 
wide columns just to name one thing. I must also completely 
disagree with the "90's anachronism" part.

You may feel that a "Getting started" section and simplified 
link/navigation structure might be insulting or inefficient, but 
is the site supposed to cater to the entrenched D-practitioners? 
As long as the readability and the layout of the documentation is 
accurate and clear what does it matter to you? There's not any 
inherent value in complexity.



 Aug 28 2014



 next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Friday, 29 August 2014 at 02:36:22 UTC, Hubert wrote:

 You may feel that a "Getting started" section and simplified 
 link/navigation structure might be insulting or inefficient, 
 but is the site supposed to cater to the entrenched 
 D-practitioners? As long as the readability and the layout of 
 the documentation is accurate and clear what does it matter to 
 you? There's not any inherent value in complexity.


I simply don't see good layout fitting into the same style. And 
having documentation sub-pages with totally different design is 
also pretty bad from the point of view of the visual style.

If you can show any sketches how it can be used for more 
technical content I may be convinced :)



 Aug 28 2014



prev sibling  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Fri, Aug 29, 2014 at 02:36:21AM +0000, Hubert via Digitalmars-d wrote:

 Thanks for the response! I do agree that the colors are way too "hot"
 (I've must've been quite tired when I submitted that mockup)
 
 Someone noted that the concept that I pitched had too much whitespace,
 which is a sentiment that I do not share. There's a lot of issues with
 the readability in the current design; way too wide columns just to
 name one thing. I must also completely disagree with the "90's
 anachronism" part.
 
 You may feel that a "Getting started" section and simplified
 link/navigation structure might be insulting or inefficient, but is
 the site supposed to cater to the entrenched D-practitioners? As long
 as the readability and the layout of the documentation is accurate and
 clear what does it matter to you? There's not any inherent value in
 complexity.


I do not say that having a simplified link/navigation structure is
insulting or inefficient. But I do say the simplification should be via
categories that make sense. I.e., "click here to start / click here to
watch completely irrelevant marketing video" makes no sense, whereas a
breakdown like "News / Download / Get started with D / Reference
documentation / Compiler specs / etc." makes sense.

Content-less splash pages are, to me, completely worthless. A
properly-designed front page with sensible top-level links to sensible
categories, properly designed, will both look and work better. A proper
design need not sacrifice content for appeal.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze



 Aug 28 2014



prev sibling  parent reply =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com>  writes:


 On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:

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




This is a brilliant idea, except for the logo. We have one, and
with it an identity, and we should not loose it.

On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:

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


There is too much links in our actual homepage, newcomers are
simply lost, we absolutely need to light it, to make it more
friendly.

The question is : is it more important to maintain your old
habits or to be welcoming and attractive for the new users ?

Don't forget that programmers are hipsters, and we need to take
care of our image.



 Aug 21 2014



 next sibling parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 21 August 2014 at 17:12:38 UTC, Théo Bueno wrote:

 On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:

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


 There is too much links in our actual homepage, newcomers are
 simply lost, we absolutely need to light it, to make it more
 friendly.

 The question is : is it more important to maintain your old
 habits or to be welcoming and attractive for the new users ?

 Don't forget that programmers are hipsters, and we need to take
 care of our image.


I prefer to have my cake and eat it at the same time. There is no 
reason why it can't have better navigation while making important 
information highlighted and visually eye-catching.

Also please avoid personal insults :P



 Aug 21 2014



  parent reply =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com>  writes:


On Thursday, 21 August 2014 at 17:15:30 UTC, Dicebot wrote:

 I prefer to have my cake and eat it at the same time. There is 
 no reason why it can't have better navigation while making 
 important information highlighted and visually eye-catching.


Of course :)


 Also please avoid personal insults :P


I wasn't insulting, my intention was to mention the fact that
this argument is not entirely a matter of productivity, but a
fear of change.



 Aug 21 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Thursday, 21 August 2014 at 17:24:28 UTC, Théo Bueno wrote:

 Also please avoid personal insults :P


 I wasn't insulting, my intention was to mention the fact that
 this argument is not entirely a matter of productivity, but a
 fear of change.


I was referring to "Don't forget that programmers are hipsters" 
statement ;)



 Aug 21 2014



  parent reply =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com>  writes:


On Thursday, 21 August 2014 at 17:31:45 UTC, Dicebot wrote:

 On Thursday, 21 August 2014 at 17:24:28 UTC, Théo Bueno wrote:

 Also please avoid personal insults :P


 I wasn't insulting, my intention was to mention the fact that
 this argument is not entirely a matter of productivity, but a
 fear of change.


 I was referring to "Don't forget that programmers are hipsters" 
 statement ;)


Oh. Let me rephrase :
Don't forget that programmers are undeclared hipsters :D



 Aug 21 2014



  parent  Matt Soucy <msoucy csh.rit.edu>  writes:


On 08/21/2014 01:37 PM, "Th=C3=A9o Bueno" <munrek gmx.com>" wrote:

 On Thursday, 21 August 2014 at 17:31:45 UTC, Dicebot wrote:

 On Thursday, 21 August 2014 at 17:24:28 UTC, Th=C3=A9o Bueno wrote:

 Also please avoid personal insults :P


 I wasn't insulting, my intention was to mention the fact that
 this argument is not entirely a matter of productivity, but a
 fear of change.


 I was referring to "Don't forget that programmers are hipsters" statem=




ent ;)

=20
 Oh. Let me rephrase :
 Don't forget that programmers are undeclared hipsters :D


Duck hipstering - if it looks like a hipster, acts like a hipster...it wa=
s a hipster before it was cool. Stop declaring your hipsters as "auto" :P=


--=20
Matt Soucy
http://msoucy.me/



 Aug 23 2014



prev sibling next sibling parent  =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com>  writes:


On Thursday, 21 August 2014 at 17:12:38 UTC, Théo Bueno wrote:

 There is too much links in our actual homepage, newcomers are
 simply lost, we absolutely need to light it, to make it more
 friendly.


Also, please see this message :
http://forum.dlang.org/thread/euxbskjjoetrwrqtklqy forum.dlang.org

It explains why we need a big red "get started" button to help
the newcomers. This person was not able to find relevant
informations on IDEs, despite our big stack of links on the
homepage. This is also a lack of productivity.



 Aug 21 2014



prev sibling  parent  ketmar via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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


 Don't forget that programmers are hipsters, and we need to take
 care of our image.


i'm glad that i'm not a programmer then.



 Aug 21 2014



prev sibling next sibling parent  "Meta" <jared771 gmail.com>  writes:


On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:

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


That does look quite nice. It may be a bit *too* minimalist, and 
the colours aren't right, but the design is solid.



 Aug 21 2014



prev sibling next sibling parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Thu, Aug 21, 2014 at 04:59:18AM +0000, Hubert via Digitalmars-d wrote:
[...]

 https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png
 
 My emphasis has been on creating a friendly first impression; a
 lightweight page to introduce newcomers to D and get them started
 quickly. I think this is a sane design approach when it comes to D's
 current position in the "market". I've not yet begun any work on the
 views for the documentation and similar pages with a larger amount of
 copy.
 
 (I hope I haven't missed any earlier design proposal that already
 looks like this.)


[...]

Please don't take this personally, but frankly, I don't like this
design. It's too minimalistic, the choice of color is too garish, and
the logo looks amateurish. There is too much space in the center of the
page, while squeezing the real information to the sides. I very much
dislike the current splash page + "get started" / "learn more" trend, an
anachronism from the 90's. It requires too much effort to get to the
meat of the site, and serves little purpose except to fill up space.
More navigation can be put on the front page without requiring
inordinate amounts of clicks to reach (properly laid out, of course, to
avoid clutter).

Having said that, though, I like the concept of putting the
"convenience, power, efficiency" slogans in a prominent place, side by
side. That's something far superior to the current layout we have, where
most people won't even see everything until they scroll down.


T

-- 
Unix is my IDE. -- Justin Whear



 Aug 21 2014



prev sibling next sibling parent  "w0rp" <devw0rp gmail.com>  writes:


On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:

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

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

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

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

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


I'm not a fan of the colours and the general way it looks, but I 
do really like the three columns of text for the three big 
points. I'm not sure how to put that on a home page and keep some 
consistent navigation in place, so that would require some 
playing around with. You could maybe sacrifice sidebar navigation 
on the home page to allow enough space to fit in the text columns 
at 1024px width, I'm not sure.

A few other people have mentioned fluid container widths. I 
actually know exactly what to do with that, I just haven't gotten 
around to doing it yet. I think I make some progress, but then 
life gets in the way a little bit. I'll come back to it soon and 
work a little more on the site.



 Aug 21 2014



prev sibling next sibling parent  "Weaseldog" <weaseldog gmail.com>  writes:


On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:

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

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

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


Sort of reminds me of Ocaml's webpage, but more minimalistic.

I think a lot of good ideas could come from looking at other 
language's webpages, Haskell's new webpage is similar to Ocaml's 
but has less content(it's also not finished yet)



 Aug 21 2014



prev sibling  parent  Matt Soucy <msoucy csh.rit.edu>  writes:


On 08/21/2014 12:59 AM, Hubert wrote:

 First I wanna say that I've become a huge fan of D, and I hope one day =


I can replace all my creative projects with a D codebase. With that said,=
 I do agree that D could use a redesign. I've not been monitoring this th=
read very closely, but the design suggestions I've seen so far has dissap=
ointed me. Don't misunderstand me; the proposals look good, but they are =
in my opinion too conservative.

=20
 Now I've given it a shot and created a first draft on how I imagine a f=


uture Dlang.org could/should look like, keep in mind that nothing is fina=
l yet:

=20
 https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png
=20
 My emphasis has been on creating a friendly first impression; a lightwe=


ight page to introduce newcomers to D and get them started quickly. I thi=
nk this is a sane design approach when it comes to D's current position i=
n the "market". I've not yet begun any work on the views for the document=
ation and similar pages with a larger amount of copy.

=20
 (I hope I haven't missed any earlier design proposal that already looks=


 like this.)

=20
=20


It reminds me a lot of http://zeromq.org/, which is TOLERABLE not not, in=
 my opinion, great.

--=20
Matt Soucy
http://msoucy.me/



 Aug 23 2014



prev sibling  parent  "yawniek" <dlang srtnwz.com>  writes:


On Monday, 28 July 2014 at 22:04:45 UTC, w0rp wrote:

 On Sunday, 27 July 2014 at 16:32:15 UTC, Sönke Ludwig wrote:

 Am 27.07.2014 00:54, schrieb w0rp:





 You can see some running examples on the site now.

 http://w0rp.com:8010/library/std.parallelism/


cool stuff, congrats on the progress, i really like it!

from a usability perspective i have two suggestions:

1) re-add the alphabetic list of classes, functions etc, either 
on top or better in a sidebar as e.g. ruby has it:
http://ruby-doc.org/core-2.2.0/String.html
it helps a lot if you are new and want to get a quick overview 
whats possible within a given module.

2) currently clicking on a function name opens a new site with 
the doc of that function.
  why not load it inline in a collapsable fragment? (could also be 
a simple + button that allows this in addition to the link)
this would greatly help when quickly going trough a number of 
functions in a module.

cheers
y



 Jan 02 2015



prev sibling  parent  Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


On 4 Jul 2014 08:40, "Russel Winder via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
 [=E2=80=A6]

 Powered by Martian Technology


  SarcasticRover is telling us "Do not come to Mars." Perhaps its
 commentary need censoring ;-)


Good advice that. :)



 Jul 04 2014



prev sibling  parent  "Chris" <wendlec tcd.ie>  writes:


On Thursday, 3 July 2014 at 17:38:22 UTC, w0rp wrote:

 On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:

 [I haven't had time to follow the entire thread, but] I like 
 the design, it's a good starting point. Especially the 
 integration of the logo. Nice and clean. (The current logo is 
 just too bulky and clumsy, imo*)

 However, my experience tells me that we should wait with 
 redesigning it until the technical issues/problems have been 
 solved, e.g. the migration to vibe.d, which I'm in favor of 
 (I've had good experiences with vibe.d so far), and the doc 
 generation issue etc etc. Once that is out of the way, we can 
 think about new designs.


 I've been focusing on getting a working site with vibe.d. 
 Integrating the ddox document generator is a high priority for 
 me right now, especially since I've finished a lot of work for 
 formatting the changelog pages.


 Yours is very nice and "modern". However, we also have to take 
 mobile devices (tablets, smartphones) into account and see how 
 we can adapt to these (different layouts or one for all?).


 I used the Bootstrap framework, which I have also used in my 
 day job. Bootstrap makes producing a responsive design pretty 
 easy. I've been periodically testing pages on smaller screens. 
 Firefox's 'reponsive design mode' helps a lot with this.


 Another issue is that we don't have to jump on any bandwagon 
 (every time the "fashion" changes), we can roll our own 
 design, one that fits the community's and the language's 
 needs, regardless of what is trendy or "modern" at any given 
 time (don't imitate, innovate!).


 There are many different designs you could produce. Many design 
 choices are subjective, though not all of them. I think my 
 goals for the work I've been doing are as follows.

 * Improve site navigation.
 * Improve display across different devices.
 * Improve the quality of text to make it easier to read.
 * Make it easier for newcomers to edit, to encourage 
 contribution.
 * Run it all with D to tick a "official D site made in D" 
 checkbox.

 There are others, but those are the important ones.


Very good. That would improve the page a lot.

The code block at the top of the page, I think we don't really 
need that for mobile devices with small screens. Takes up too 
much space. Maybe we could just hide it and have a button or so 
that says "show code".

I'd also recommend a page with simple recipes "how to open a 
file" etc. In this way newbies wouldn't have to go through the 
library reference for simple tasks.

I'd love to use something like "Powered by D" for my own programs 
written in D.



 Jul 08 2014



prev sibling  parent reply "BBaz" <basile.burg gmx.com>  writes:


On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic 
wrote:

 Hello,

 I've been D enthusiast for couple of years now (but I do not 
 participate much in discussions here, although I read forums 
 almost daily), and I keep telling people about D and how 
 awesome it is.

 But, all this time D's official website somehow archaic look 
 kept troubling me. It reminds me of early 2000's design and I 
 really cannot associate this design with "modern" or "elegant", 
 what D really is.
 I think that we must invest time and energy improving the 
 website's look and feel as that is what people first coming to 
 D will see. We need to strive for "wow" and not "meh" as a 
 first impression.

 So I have started this thread to see if there is a chance for 
 complete redesign of dlang.org.

 I have also tried to design something myself (although I'm not 
 a designer) and this is what I came up with:

 http://krcko.net/dlang.org/dlang-home-draft1.png

 I'm not entirely satisfied with it but I believe that it looks 
 better (or at least more modern) than the current design.


 So, what do you guys think?




 -- Aleksandar


What's up with this new website design ?
Drafts looked good.



 Dec 09 2014



  parent reply "Martin Nowak" <code dawg.eu>  writes:


 What's up with this new website design ?
 Drafts looked good.


Yeah, draft looks good, but this didn't got the priority and 
support it deserves.
My plan is to incrementally improve the current website until it 
looks reasonable.
Already submitted a bunch of pulls.
You can see a preview here https://dlang.dawg.eu.



 Dec 11 2014



 next sibling parent  "Martin Nowak" <code dawg.eu>  writes:


On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:

 Already submitted a bunch of pulls.


https://github.com/D-Programming-Language/dlang.org/pulls?q=is%3Apr+author%3AMartinNowak+is%3Aclosed

I'd be thankful for any help on that.
Cloning dlang.org and running make -f posix.mak should work 
currently, so it's easy to try out ideas.



 Dec 11 2014



prev sibling  parent  =?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com>  writes:


On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:

 What's up with this new website design ?
 Drafts looked good.


 Yeah, draft looks good, but this didn't got the priority and 
 support it deserves.


So, is it dead already ?



 Jan 01 2015