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 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
prev sibling parent 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
prev 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 "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 "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
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?

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
next sibling 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
next sibling parent =?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
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 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
prev sibling 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 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 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
prev sibling next sibling 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 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 

 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
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 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 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 "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
prev sibling 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 "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 "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?

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
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 "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
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
parent 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
prev sibling next sibling 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 next sibling parent 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
prev sibling next sibling parent "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?

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
prev sibling 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 next sibling 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:
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 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 "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
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 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
prev sibling next 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:

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 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
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 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 next 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 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
prev sibling 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 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 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
next sibling 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. Of course, I am aware that #000000/#FFFFFF can be a bit too much 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 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
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 next 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 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 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 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 parent 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
prev sibling parent "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
prev sibling next sibling parent 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
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
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 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 "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 "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 "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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?

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
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 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.

 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
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
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 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
next sibling parent 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
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 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
prev sibling next 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 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 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
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 next 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 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
prev sibling next sibling 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
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 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
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 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 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 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 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
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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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.

 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
prev sibling next sibling parent "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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling 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 "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

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

 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

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

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

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

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

 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling 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 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
--001a11c3ce54b9ccfb04f7754dc8
Content-Type: text/plain; charset=UTF-8

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


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. --001a11c3ce54b9ccfb04f7754dc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr"><br> On 19 Apr 2014 13:00, &quot;Lars T. Kyllingstad via Digitalmars-d&quot; &lt= ;<a href=3D"mailto:digitalmars-d puremagic.com">digitalmars-d puremagic.com= </a>&gt; wrote:<br> &gt;<br> &gt; On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer wrote:<= br> &gt;&gt;<br> &gt;&gt; I don&#39;t share your opinion that the web site need to be &quot;= modern&quot; to avoid warding off potential adopters. If they are turned of= f of using a system programming language by a bland (debatable) site look a= nd feel, then I think there was really something else bothering them.<br> &gt;<br> &gt;<br> &gt; Case in point: <a href=3D"http://gcc.gnu.org/">http://gcc.gnu.org/</a>= </p> <p dir=3D"ltr">What&#39;s wrong with that site? Everything is clear to find= and readable.</p> --001a11c3ce54b9ccfb04f7754dc8--
Apr 20 2014
prev sibling next sibling 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 next sibling 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


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 "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!

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.

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.

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
prev sibling next sibling parent "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
prev sibling next 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent reply "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
next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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, Snke Ludwig wrote:
Am 24.04.2014 17:34, schrieb "Ola Fosheim Grstad"
<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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling 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 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 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 next sibling 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!

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.

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.

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 "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
prev sibling 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

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
prev sibling next 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 next sibling parent "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
prev sibling 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 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.

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 next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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
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 "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent 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.

Please let me know if you need any help to make this happen.
Apr 22 2014
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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.

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 "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
prev sibling next sibling parent "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
prev sibling next 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling 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 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
parent "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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 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 next sibling 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 next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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?

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.

;) So not a worry.
 The implementation is pretty much a brute force string search 
 in a replace loop.

Apr 24 2014
prev sibling next sibling 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 next sibling 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 next 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 "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 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
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 =?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 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 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
next 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 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 =?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 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 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 next 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 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
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 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 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 =?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
prev sibling next sibling 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 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 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 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 parent 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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 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 "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
prev sibling next sibling 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 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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 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 next sibling 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 next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
Shouldn't it be measured in characters instead of percentage of 
page width?
Jun 03 2014
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
prev sibling 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 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 next sibling parent "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=


 some strong proponents of using DDOC for things, so it would be bad i=


 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=

 ddoc we should switch to something better, not something just differen=

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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
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 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
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 "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 next sibling parent "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
prev sibling 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 next sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 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 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 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 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 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
next sibling 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 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 =?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 =?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
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
next sibling parent =?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
prev 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 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 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
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 =?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
next sibling parent =?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
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 Matt Soucy <msoucy csh.rit.edu> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=


=20
 Oh. Let me rephrase :
 Don't forget that programmers are undeclared hipsters :D

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 parent Matt Soucy <msoucy csh.rit.edu> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 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=

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=

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=

=20
=20

my opinion, great. --=20 Matt Soucy http://msoucy.me/
Aug 23 2014
prev sibling next sibling parent "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
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
--001a11c13d125e0af904fd587b22
Content-Type: text/plain; charset=UTF-8

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

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 --001a11c13d125e0af904fd587b22 Content-Type: text/html; charset=UTF-8 <p dir="ltr">On 3 Jul 2014 20:45, &quot;Alix Pexton via Digitalmars-d&quot; &lt;<a href="mailto:digitalmars-d puremagic.com">digitalmars-d p remagic.com</a>&gt; wrote:<br> &gt;<br> &gt; On 03/07/2014 6:38 PM, w0rp wrote:<br> &gt;<br> &gt;&gt; * Run it all with D to tick a &quot;official D site made in D&quot; checkbox.<br> &gt;<br> &gt;<br> &gt; The &quot;powered by Python&quot; banner gave me an idea...<br> &gt;<br> &gt; In a nod to Walter&#39;s self confessed petrol-headedness, I thought we could incorporate the logo into a &quot;D under the hood&quot; or &quot;D in the tank&quot; banner for sites and software that utilise or run on D.<br> &gt;<br> &gt; Might be a bit over the top for <a href="http://dlang.org">dlang.org</a> though ^^<br> &gt;<br> &gt; A...<br> &gt;</p> <p dir="ltr">Powered by Martian Technology</p> --001a11c13d125e0af904fd587b22--
Jul 03 2014
prev sibling next sibling parent 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
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
--001a11c13e94b8fc8904fd5ccf4e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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. :) --001a11c13e94b8fc8904fd5ccf4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p dir=3D"ltr"><br> On 4 Jul 2014 08:40, &quot;Russel Winder via Digitalmars-d&quot; &lt;<a hre= f=3D"mailto:digitalmars-d puremagic.com">digitalmars-d puremagic.com</a>&gt= ; wrote:<br> &gt;<br> &gt; On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote= :<br> &gt; [=E2=80=A6]<br> &gt; &gt; Powered by Martian Technology<br> &gt;<br> &gt; SarcasticRover is telling us &quot;Do not come to Mars.&quot; Perhaps= its<br> &gt; commentary need censoring ;-)<br> &gt;</p> <p dir=3D"ltr">Good advice that. :)<br> </p> --001a11c13e94b8fc8904fd5ccf4e--
Jul 04 2014
prev sibling next 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 next sibling parent "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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 sticking with C/C++ and app devs are sticking with Java/C# so we 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
prev sibling next sibling 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 "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 next sibling 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 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 next 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 "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 next sibling parent "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
prev sibling next sibling 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 "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 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
next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 "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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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.

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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent =?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
prev sibling next sibling parent "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
prev sibling next sibling parent =?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
prev sibling next sibling parent "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
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 next sibling parent =?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
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 "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 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 next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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.

Aug 21 2014
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
prev 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.

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