## digitalmars.D - Redesign of dlang.org

• Aleksandar Ruzicic (22/22) Apr 18 2014 Hello,
• Steven Schveighoffer (14/32) Apr 18 2014 Great!
• David Gileadi (35/75) Apr 18 2014 As the guy who was mostly responsible for the current look and feel of
• Andrei Alexandrescu (5/8) Apr 18 2014 We can (and probably should) integrate server-side scripting as well.
• Aleksandar Ruzicic (3/13) Apr 18 2014 I think that having vibe.d behind dlang.org would be great!
• Brad Anderson (16/26) Apr 18 2014 I assume moving from DDoc to something like Vibe'd's Jade
• Jacob Carlborg (6/9) Apr 19 2014 Yes please. Ddoc might be better than plain HTML but most other
• alexhairyman (4/14) Apr 21 2014 Going the vibe.d route would be great for advertising D as an all
• Aleksandar Ruzicic (28/64) Apr 18 2014 I know about DDoc usage, I already know it and using it, so that
• Brad Anderson (6/29) Apr 18 2014 Phew...you narrowly avoided a Nick/Teoh JS rant there :P.
• Aleksandar Ruzicic (3/6) Apr 18 2014 Thanks! I haven't worked with ddox yet but I'm looking forward to
• David Gileadi (15/36) Apr 18 2014 I'm having trouble finding the thread, but I think the idea was to use
• Aleksandar Ruzicic (6/14) Apr 18 2014 I just need to motivate them somehow. Designers are a bit strange
• Aleksandar Ruzicic (23/34) Apr 18 2014 I agree that it's not a significant improvement. As I've said I'm not a ...
• Iain Buclaw via Digitalmars-d (4/35) Apr 18 2014 Really? To me it looks like the OP is mimicking Github dccumentation pa...
• Aleksandar Ruzicic (8/11) Apr 18 2014 I really like the look of Read the Docs and it's something I
• Lars T. Kyllingstad (3/8) Apr 19 2014 Case in point: http://gcc.gnu.org/
• Christof Schardt (5/13) Apr 18 2014 Me too.
• captaindet (2/3) Apr 18 2014 i like it.
• Frustrated (8/30) Apr 18 2014 I like it too. A little cleaner/sharper. A little more balanced.
• Aleksandar Ruzicic (8/14) Apr 18 2014 It's just first a mockup, but it's a direction in which I think
• Wyatt (10/11) Apr 18 2014 I _strongly_ suggest any proposed redesign retain the
• Aleksandar Ruzicic (13/26) Apr 18 2014 I must respectfully disagree about retaining left justification.
• Steven Schveighoffer (5/22) Apr 18 2014 Making something that works like this would be excellent:
• John Colvin (4/32) Apr 18 2014 Or just a little switch in a corner somewhere to change the
• Aleksandar Ruzicic (4/6) Apr 19 2014 That can be easily done (although I wouldn't use cookies) but I
• Nick Sabalausky (6/12) Apr 19 2014 (left/right/centered) Layout != (left/right/centered/justified) text
• Jacob Carlborg (6/9) Apr 19 2014 Agree. I think we should use Bootstrap. Then we can also get a
• Aleksandar Ruzicic (6/16) Apr 19 2014 Bootstrap is great but I wouldn't use it for this project. As it
• Jacob Carlborg (9/14) Apr 19 2014 I haven't really tried designing a web site with Bootstrap without
• Aleksandar Ruzicic (9/26) Apr 19 2014 Official Sass support for Bootstrap is news to me, thanks for
• Aleksandar Ruzicic (11/11) Apr 19 2014 Ok here's a mockup of search concept I would like to implement:
• Iain Buclaw via Digitalmars-d (4/15) Apr 19 2014 I'm more a fan of Solr myself.
• Aleksandar Ruzicic (6/34) Apr 19 2014 I have experience with ElasticSearch but I'm open to all
• Jacob Carlborg (4/8) Apr 20 2014 They're quire similar. Both builds on Lucene.
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (4/15) Apr 19 2014 Note that for the new library documentation layout a similar search
• Aleksandar Ruzicic (3/31) Apr 19 2014 That's excellent news! Would it be possible to use it to search
• Nick Sabalausky (12/16) Apr 19 2014 I don't know anything about the specific search-suggestion engines, but
• Aleksandar Ruzicic (11/34) Apr 19 2014 OK, I'll work on a design more, I'll also try to have real
• Nick Sabalausky (6/27) Apr 19 2014 Honestly, I think you're selling yourself short here. You appear to have...
• Aleksandar Ruzicic (6/27) Apr 19 2014 Heh, that's nice to hear, tnx! :) But I have never before
• Martin Nowak (4/7) Apr 23 2014 You could make a poll on the newsgroup or ask Andrei if Google
• Aleksandar Ruzicic (5/12) Apr 23 2014 I would support IE8 too, as that is the latest IE you can get on
• Martin Nowak (5/12) Apr 23 2014 Yes it would. It could be done as an independent second step
• Aleksandar Ruzicic (7/21) Apr 23 2014 Yep, that's how I plan to do it. First just to redesign the
• Kagamin (11/18) Apr 19 2014 You can have the browser window centered on screen and have your
• Aleksandar Ruzicic (19/39) Apr 19 2014 I like my browser window maximized, that's how I've been using it
• Nick Sabalausky (5/10) Apr 19 2014 I get "This site is asking to store data on your computer for offline us...
• Aleksandar Ruzicic (8/24) Apr 19 2014 They use it to remember your selection of languages/frameworks if
• Nick Sabalausky (7/11) Apr 19 2014 Session cookies are a few **bytes** in size. Selection of
• Aleksandar Ruzicic (13/27) Apr 19 2014 Yes they are few bytes but they are sent for *every* request.
• Nick Sabalausky (14/32) Apr 19 2014 Doesn't matter if you're talking server or client, it's still the same
• Nick Sabalausky (11/20) Apr 19 2014 Why does everyone these days seem to forget that windows are resizable?
• Wyatt (19/27) Apr 21 2014 Yeah, me too...
• Aleksandar Ruzicic (14/46) Apr 21 2014 I have by browser's window maximized and websites with lot of
• Brad Anderson (12/19) Apr 18 2014 Even if it weren't better looking, just different, I'd say it
• Peter Alexander (4/9) Apr 18 2014 Agreed.
• Kagamin (4/5) Apr 18 2014 Isn't it only Microsoft PR department, who call metro style
• Aleksandar Ruzicic (7/12) Apr 18 2014 This is not really a "metro design", but I admit it sure looks a
• "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (7/11) Apr 18 2014 Nice initiative, but the top bar looks a lot like adobe.com . I
• Nick Sabalausky (15/21) Apr 18 2014 I'm normally very skeptical and critical of "staying modern" (and
• 1100110 (5/11) Apr 18 2014 I REALLY like the new look. I think it's about time to change the
• Aleksandar Ruzicic (5/23) Apr 19 2014 Thanks! I'm planning to start working on this as soon as I get
• Nick Sabalausky (7/13) Apr 19 2014 Although I empathize with not wanting to put the full work into
• Aleksandar Ruzicic (3/21) Apr 19 2014 Ok then. Given that I haven't received up-front rejections I'll
• Martin Nowak (5/11) Apr 24 2014 Getting more feedback during early development would help.
• Andrei Alexandrescu (2/5) Apr 20 2014 Let's do it. Thank you very much! -- Andrei
• Aleksandar Ruzicic (3/10) Apr 21 2014 Great! I'll start tonight! :)
• Aleksandar Ruzicic (8/15) Apr 21 2014 Just one question, would it be okay to depend on node.js/npm to
• Andrei Alexandrescu (6/18) Apr 21 2014 Ionno. Not an expert, but I'd say the fewer dependencies the better. Add...
• Aleksandar Ruzicic (13/39) Apr 21 2014 Understood.
• David Gileadi (5/14) Apr 21 2014 A little searching turned up libsass.org which apparently is the native
• Aleksandar Ruzicic (3/25) Apr 21 2014 Yep, forgot to mention that libsass (used by node-sass) is
• Aleksandar Ruzicic (9/31) Apr 21 2014 Oh, I forgot to mention that I'm not advocating the use of
• Andrei Alexandrescu (14/18) Apr 21 2014 Well you'd be surprised. But the same guideline applies - the tool needs...
• Jacob Carlborg (5/15) Apr 21 2014 Sass doesn't overlap with ddoc.
• Andrei Alexandrescu (18/31) Apr 22 2014 I'm clearly outta my depth here, basing myself off of giving
• Jacob Carlborg (7/20) Apr 22 2014 I'm not going to argue which is best. But since I started to use Sass, I...
• Aleksandar Ruzicic (11/35) Apr 22 2014 I'm no Rails (or Ruby) developer but I use Sass for all my
• Aleksandar Ruzicic (49/94) Apr 22 2014 It's not competing with Sass. Sass would make it easier for me to
• Adam D. Ruppe (9/9) Apr 22 2014 I wrote a css expander that has a little bit of SASS features.
• Aleksandar Ruzicic (9/18) Apr 22 2014 Wow, this looks really nice! It has variables, mixins, nested
• Adam D. Ruppe (15/21) Apr 23 2014 Yea, I wrote this several years ago before even knowing about
• Nick Sabalausky (3/12) Apr 23 2014 "box-sizing: border-box" is proof of what I've said all along: Microsoft...
• Rikki Cattermole (5/14) Apr 22 2014 Any chance to get this separated out just for the css part of it?
• Adam D. Ruppe (10/13) Apr 23 2014 Hmm, you know, maybe that wouldn't be too hard. I thought it used
• John Colvin (6/15) Apr 23 2014 This is awesome. I think I might try it out for my next web-dev
• Nick Sabalausky (4/23) Apr 23 2014 SCSS has always been more interesting to me than SASS, but yea, this
• Adam D. Ruppe (7/10) Apr 23 2014 The funny thing is I wrote this thing a few years ago, 2011 I
• Jacob Carlborg (7/10) Apr 23 2014 Technically, Sass is the name of the language. It provides two syntaxes,...
• Adam D. Ruppe (2/3) Apr 23 2014 http://code.dlang.org/packages/cssexpand
• Rikki Cattermole (3/6) Apr 23 2014 Can we have it as a library? Instead of as only an executable?
• Martin Nowak (6/9) Apr 24 2014 Nice, thanks a lot. How much effort would it be to turn this into
• Adam D. Ruppe (62/64) Apr 24 2014 Hmm, looking at the sass webpage, I think I could do some of the
• Jacob Carlborg (5/8) Apr 24 2014 Sass really has some advanced features. It's possible to create a
• Adam D. Ruppe (5/7) Apr 24 2014 Yeah, going that far definitely isn't feasible. But I don't think
• Nick Sabalausky (5/8) Apr 22 2014 FWIW, on windows:
• Dicebot (4/21) Apr 21 2014 I think it is very important to dogfood here and add any
• Jacob Carlborg (5/7) Apr 21 2014 Unless we can use libsass, I would say it's not very productive to
• "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (18/20) Apr 22 2014 I never use css macros-tools, regular template libraries are
• Jacob Carlborg (7/12) Apr 22 2014 I usually use these languages together with Ruby on Rails. With the
• Dicebot (5/11) Apr 22 2014 I think using libsass is superior to using node/npm based
• Aleksandar Ruzicic (5/19) Apr 22 2014 I see what you mean. I get that it wouldn't be good marketing so
• Dicebot (7/28) Apr 23 2014 You can do dub fetch package; dub run package AFAIR for
• Martin Nowak (3/8) Apr 22 2014 Why do you want to write the whole CSS yourself? Isn't something like
• Nick Sabalausky (4/13) Apr 22 2014 Apparently they can't even manage make basic links work properly:
• Aleksandar Ruzicic (3/15) Apr 22 2014 I would use Foundation[1] instead of Bootstrap.
• Nick Sabalausky (8/14) Apr 22 2014 Eww. Font size and image scaling should *not* be a function of window
• Martin Nowak (3/10) Apr 22 2014 Yeah, let's have a page like Peter Norvig (http://norvig.com).
• Adam D. Ruppe (2/5) Apr 23 2014 There's a middle ground here.
• Nick Sabalausky (3/14) Apr 23 2014 I didn't say style was irrelevent. I only said that there should
• Martin Nowak (3/9) Apr 23 2014 Sorry for the irony :), indeed fluffy sites without content are
• Martin Nowak (7/9) Apr 23 2014 Whatever gets the job done. I haven't yet worked with Foundation,
• Aleksandar Ruzicic (8/19) Apr 23 2014 I was thinking of that too, but I used this approach on one of
• Martin Nowak (2/12) Apr 23 2014 I think this will work out nice, css doesn't change very often.
• Kapps (28/30) Apr 18 2014 I do agree that the design of the current site is rather dated. I
• Aleksandar Ruzicic (22/53) Apr 19 2014 It sure looks like a button and it wouldn't be a button. It would
• Rikki Cattermole (5/12) Apr 19 2014 On Saturday, 19 April 2014 at 08:16:20 UTC, Aleksandar Ruzicic
• Nick Sabalausky (12/28) Apr 19 2014 I use a browser extension to disable backspace navigation since I get
• Kagamin (12/20) Apr 21 2014 Autofocus breaks site navigation: instead of returning to where
• Lars T. Kyllingstad (10/16) Apr 21 2014 I hate that too. It also breaks in-page search with "/", which I
• Aleksandar Ruzicic (5/22) Apr 21 2014 Agreed. But given that I'll be implementing "preferences page"
• Martin Nowak (2/2) Apr 25 2014 Different strokes for different folks.
• w0rp (23/23) Apr 22 2014 I like your design. Go forth and make it happen.
• Martin Nowak (2/7) Apr 22 2014 This looks great, finally something that doesn't scare off people.
• Aleksandar Ruzicic (5/18) Apr 22 2014 Thanks! I'll be pushing all my work to GitHub from day one (I'll
• H. S. Teoh via Digitalmars-d (39/76) Apr 24 2014 [...]
• David Gileadi (2/2) May 06 2014 Is this still happening? Is there a repo or a place I can go to
• Brad Anderson (3/25) May 29 2014 Any updates? Any help needed pushing this forward?
• w0rp (62/62) May 31 2014 After watching Andrei's keynote where he was asking for help, and
• Dylan Knutson (17/17) May 31 2014 Firstly, wow, the site looks beautiful. It has an air of
• w0rp (10/27) May 31 2014 Yeah, that's why I was mentioning something about hosting drepl
• Meta (3/3) May 31 2014 The flat design looks nice, but I really dislike the choice of
• Meta (5/8) May 31 2014 For comparison, here's two images. One is the site with the
• Meta (2/10) May 31 2014 Whoops. http://imgur.com/oSHfFek,Mc81UYM
• w0rp (2/13) May 31 2014 Yes, a darker background does look quite nice.
• Russel Winder via Digitalmars-d (15/30) May 31 2014 Contrast level is still a bit high though. The current dlang.org also
• Jacob Carlborg (5/12) Jun 02 2014 I tried and changed the background color of the #page-wrapper element to...
• w0rp (8/25) Jun 02 2014 By the way, feel free to contribute to development of the new
• Kapps (15/22) May 31 2014 I definitely like it. It scales fairly nicely, and works on high
• w0rp (4/13) May 31 2014 Yes, that line should be smaller. Maybe the download link at the
• FG (3/4) Jun 01 2014 Or just put nbsp between Native and efficiency.
• deadalnix (2/64) May 31 2014 I love you. Will you marry me ?
• Kiith-Sa (9/71) May 31 2014 Looks better than what we have now.
• w0rp (9/17) May 31 2014 I think the trick is to have very brief 'above the fold' content.
• Rikki Cattermole (24/79) May 31 2014 The problem with diet is it compiles directly to D code, hence forth its...
• w0rp (14/33) Jun 01 2014 I would also consider using a different template engine entirely,
• Russel Winder via Digitalmars-d (56/127) May 31 2014 I have to admit my initial reaction on seeing this was: oh no not
• w0rp (14/32) Jun 01 2014 Yes, that is a deployment issue. Deployment is a hot issue for
• FG (3/6) Jun 01 2014 Please, no. Whatever you do, don't create something this hideous. :)
• w0rp (31/31) Jun 01 2014 I just updated the site. Here are the main changes.
• Brad Anderson (4/6) Jun 01 2014 Had to force a refresh to see the changes. I can't decide if I
• w0rp (4/11) Jun 01 2014 You just reminded me to put in a query string version hack at
• w0rp (10/10) Jun 01 2014 https://github.com/w0rp/new-dlang.org/blob/master/src/dlang/toc.d
• Jacob Carlborg (7/10) Jun 02 2014 That's not reliable. It's usually assets that are the problem, CSS, JS,
• Rusty D. Shackleford (4/14) Jun 01 2014 I find the dark background pretty hard on the eyes in contrast
• Kagamin (2/2) Jun 02 2014 Hmm... doesn't scale well, the main text remains crammed into
• w0rp (4/6) Jun 03 2014 There should be a maximum width on the text you read on a page.
• Kagamin (2/2) Jun 03 2014 Shouldn't it be measured in characters instead of percentage of
• w0rp (34/34) Jun 09 2014 I have updated the site and the repository with all of the D
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (19/49) Jun 10 2014 Sounds kind of like an ironic joke when viewed from a C++ background ;)
• w0rp (7/13) Jun 10 2014 Indeed, this is a front end issue. I'm considering switching to
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (10/22) Jun 10 2014 If you go down the Markdown route*, let's extend the
• Dicebot (4/9) Jun 10 2014 DDOC was promoted because of dog-fooding rationale but I believe
• w0rp (10/19) Jun 10 2014 I think the key advantage for Markdown is that it's well
• Jacob Carlborg (5/8) Jun 10 2014 I think Ddoc is fine for API documentation, but not for designing a web
• Kiith-Sa (9/43) Jun 10 2014 Definitely support Markdown.
• Russel Winder via Digitalmars-d (18/34) Jun 10 2014 Isn't DDoc for generating API documentation is the vein of Doxygen,
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (3/7) Jun 10 2014 Agreed. The Markdown parser in vibe.d does support some of the GitHub
• w0rp (3/14) Jun 10 2014 I can definitely live without Markdown style tables. I'm happy
• w0rp (40/40) Jun 20 2014 I thought I'd post an update on this work so I don't leave any
• w0rp (7/7) Jun 29 2014 I just finished translating all of the pages I have worked on so
• David Gileadi (2/8) Jun 30 2014 This is looking really good!
• Gary Willoughby (4/11) Jun 30 2014 Please use the correct logo and the correct colours. Branding is
• David Gileadi (5/16) Jun 30 2014 My opinion is that the redesign preserves the spirit of the current logo...
• w0rp (6/17) Jun 30 2014 The logo on the site I'm testing is the most effective duck.
• Alix Pexton (8/13) Jul 01 2014 I just found out why your logo looks terrible on my machine, you are
• Alix Pexton (5/19) Jul 01 2014 However, the font is Apache licensed, so to use it in a logo you would
• w0rp (7/25) Jul 01 2014 Ah, I didn't realise the SVG was loading a font for that, I
• w0rp (3/32) Jul 01 2014 I'll fix that in the interim by converting the font into a shape
• Gary Willoughby (7/15) Jul 01 2014 No! You must use the original D logo, this is not up for debate.
• Dicebot (5/20) Jul 01 2014 Doing logo restyling together with web site update is not unheard
• Jacob Carlborg (5/9) Jul 01 2014 Some companies also use different versions of their logo for different
• David Nadlinger (5/10) Jul 01 2014 I'd say your zeal is a bit misdirected. "Professional" brands are
• Brad Anderson (4/19) Jul 01 2014 The copyright of the original isn't owned by Walter. I think it'd
• Alix Pexton (5/7) Jul 01 2014 Should anyone ever deem one of my designs worthy, I'd be happy to sign
• Dicebot (4/11) Jul 01 2014 I really appreciate quick links to current page headers added to
• Shammah Chancellor (3/10) Jul 01 2014 This looks awesome. I like the new logo also. Keep up the good work.
• deadalnix (2/13) Jul 02 2014 It is not about liking it or not...
• w0rp (8/8) Jul 02 2014 I just brought the Twitter module back. I decided to run with
• Suliman (2/2) Jul 02 2014 I think it's better to remove mention about D1 on main page. It's
• Dicebot (3/4) Jul 03 2014 :( it was so much better with this ugly widget gone and replaced
• w0rp (4/8) Jul 03 2014 I actually didn't intend to remove it before, but if we want to
• Alix Pexton (10/19) Jul 03 2014 The twitter feed on D currently fulfils the role that in other places is...
• Dicebot (6/15) Jul 03 2014 I'd prefer to see it removed but pretty sure many will be against
• Andrei Alexandrescu (6/10) Jun 10 2014 I think ddoc is a lot more flexible than markdown, and I'm baffled by
• Jacob Carlborg (5/10) Jun 10 2014 Can the templates be compiled in a separate phase, not using CTFE but as...
• Puming (4/16) Jun 10 2014 Or, just like ctRegx vs regx, can we have a runtime version of
• Dicebot (3/21) Jun 10 2014 We can't because Diet templates may contain arbitrary D code
• Jacob Carlborg (10/29) Jun 02 2014 I kind of like it. It would be nice to see examples of a couple of other...
• w0rp (11/19) Jun 02 2014 Yes, I plan to follow the usual pattern for having a drop down
• Dicebot (6/11) Jun 02 2014 Looks good! Can twitter widget be forced to rescale on wider
• Jacob Carlborg (4/6) Jun 02 2014 Agree. This would also make a reason for me to learn vibe.d.
• Uranuz (6/28) Jul 01 2014 Looks pretty well. What I don't like is dark background for
• Chris (23/45) Jul 03 2014 [I haven't had time to follow the entire thread, but] I like the
• w0rp (19/37) Jul 03 2014 I've been focusing on getting a working site with vibe.d.
• Alix Pexton (7/8) Jul 03 2014 The "powered by Python" banner gave me an idea...
• Iain Buclaw via Digitalmars-d (5/11) Jul 03 2014 incorporate the logo into a "D under the hood" or "D in the tank" banner
• Russel Winder via Digitalmars-d (11/12) Jul 04 2014 @SarcasticRover is telling us "Do not come to Mars." Perhaps its
• deadalnix (4/11) Jul 08 2014 He also get angry when you mention that using the imperial system
• Iain Buclaw via Digitalmars-d (4/18) Jul 08 2014 But the imperial system *isn't* idiotic. :o)
• Alix Pexton (4/6) Jul 08 2014 I drive in the middle, it works fine until I meet other road users.
• Chris (11/34) Jul 09 2014 Driving on the left goes back to the times when coaches
• Alix Pexton (18/28) Jul 09 2014 Driving on the left actually originates from jousting. On a tilting yard...
• Chris (8/49) Jul 09 2014 This sounds just like Imperial education. Very interesting how it
• Alix Pexton (11/17) Jul 09 2014 Sorry, the correct side/wrong side designations was all me, I have
• Chris (14/38) Jul 10 2014 I see. Your account of what you learned is interesting
• w0rp (20/20) Jul 26 2014 http://w0rp.com:8010/library/index.html
• Dicebot (4/4) Jul 26 2014 ..and fixed width docs again. Unfortunately I am not competent
• H. S. Teoh via Digitalmars-d (12/22) Jul 26 2014 What do you think about using tables for the functions under each
• w0rp (4/29) Jul 26 2014 The std.algortihm documentation doesn't look good, and I don't
• Andrei Alexandrescu (3/5) Jul 26 2014 I find std.algorithm among the best documented libraries out there! I
• H. S. Teoh via Digitalmars-d (5/11) Jul 26 2014 "No, I'm not in denial! It can't be!!!"
• Andrei Alexandrescu (3/11) Jul 26 2014 Well correction: I think it's among the better documented modules in
• w0rp (16/31) Jul 27 2014 It's not the text, it's just the current formatting. The cheat
• Gary Willoughby (17/32) Jul 27 2014 This is completely the wrong way to design anything. The design
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (11/16) Jul 27 2014 I really wish you'd stop with this destructive attitude. Yes, the web
• Gary Willoughby (2/5) Jul 28 2014 Since when is the truth destructive?
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (11/16) Jul 28 2014 "completely the wrong way to design anything.", "current design look
• Gary Willoughby (20/32) Jul 28 2014 No, that's the truth! You can sugar coat it all you want but at
• Andrei Alexandrescu (3/10) Jul 28 2014 No, if you want professional results you have to do professional work.
• Gary Willoughby (31/48) Jul 28 2014 Of course, but you have to be honest when things are not going
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (13/26) Jul 28 2014 Yes, I don't try to argue against the importance of the design. The
• w0rp (22/61) Jul 28 2014 I'm not a designer. I'm a web developer. My understanding of web
• Andrei Alexandrescu (3/18) Jul 28 2014 Being honest does not entail being a jerk. -- Andrei
• Dicebot (9/15) Jul 29 2014 Current web site has certain purely technical issues that
• Kagamin (7/9) Jul 29 2014 I've seen an expressed concern here (probably by Nick) about
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (46/77) Jul 28 2014 That may be the case in a professional setting where everyone is payed
• w0rp (40/75) Jul 27 2014 If you would like to contribute to the project, I am more than
• H. S. Teoh via Digitalmars-d (9/16) Jul 27 2014 I'm not a professional web developer, but isn't the current convention
• Gary Willoughby (13/37) Jul 28 2014 No, the current design is too small, period. Everything about it
• w0rp (25/62) Jul 28 2014 You wouldn't fit a very large page of sample code on a slide if
• Gary Willoughby (19/28) Jul 28 2014 I'm speaking the truth which often hurts.
• uri (11/31) Jul 28 2014 Yes and I don't see w0rp running off and sulking about it either.
• Dicebot (8/11) Jul 28 2014 Criticism is worthless if you are not ready to actually do
• Andrei Alexandrescu (6/11) Jul 28 2014 I've been in similar situations in the past so I sympathize. The one
• Gary Willoughby (15/31) Jul 28 2014 It is frustrating because i want this to be done well as it could
• Kagamin (9/12) Jul 29 2014 Doing it on LAMP won't help D to take off. In a sense, you don't
• H. S. Teoh via Digitalmars-d (16/26) Jul 28 2014 Your hostile tone may have contributed to that reaction, however
• deadalnix (3/18) Aug 21 2014 Still, all the documentation do not looks good.
• Timon Gehr (3/8) Jul 28 2014 ^~~~~~~~~~~~~~~~~~~
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (5/6) Jul 27 2014 Since the site is running with vibe.d anyway, I'd think about using
• w0rp (32/40) Jul 28 2014 I have just been playing with this during this evening by
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (15/49) Jul 28 2014 The DocGroupContext class currently returns null for its
• w0rp (4/16) Jul 28 2014 That's probably a good call. Were you thinking of discovering
• =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (4/17) Jul 29 2014 The other way around. DDOX and the Markdown processor would directly
• w0rp (5/31) Jul 29 2014 Sounds good to me. This is starting to remind me of Inception. A
• Colin (3/36) Jul 29 2014 Confusing sentence. Deception at it's finest.
• Anonymous (12/12) Jul 30 2014 Random guy here. I think the redesign is good. Populating the On
• Hubert (19/19) Aug 20 2014 First I wanna say that I've become a huge fan of D, and I hope
• "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (6/12) Aug 21 2014 +1 Cool look! The paragraphs need to be black on light background
• Jacob Carlborg (4/5) Aug 21 2014 I kind of like the structure of the page, but not the colors.
• Dicebot (5/24) Aug 21 2014 It probably looks good as a landing page for a newcomers but I
• ketmar via Digitalmars-d (3/7) Aug 21 2014 exactly what i wanted to say, but cannot find the appropriate words!
• Kagamin (4/8) Aug 21 2014 Hmm... I don't remember, when I last visited the front page, I
• Dicebot (5/13) Aug 21 2014 I check various parts of documentation (not DDOC-generates Phobos
• "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (20/24) Aug 21 2014 But you will get all that from the documentation subsection?
• Kagamin (5/19) Aug 24 2014 Such things should be probably integrated in a documentation
• Hubert (13/13) Aug 28 2014 Thanks for the response! I do agree that the colors are way too
• Dicebot (6/12) Aug 28 2014 I simply don't see good layout fitting into the same style. And
• H. S. Teoh via Digitalmars-d (14/29) Aug 28 2014 I do not say that having a simplified link/navigation structure is
• =?UTF-8?B?IlRow6lv?= Bueno" (10/16) Aug 21 2014 This is a brilliant idea, except for the logo. We have one, and
• Meta (3/4) Aug 21 2014 That does look quite nice. It may be a bit *too* minimalist, and
• H. S. Teoh via Digitalmars-d (20/31) Aug 21 2014 [...]
• w0rp (13/32) Aug 21 2014 I'm not a fan of the colours and the general way it looks, but I
• Weaseldog (5/14) Aug 21 2014 Sort of reminds me of Ocaml's webpage, but more minimalistic.
• Matt Soucy (18/29) Aug 23 2014 I can replace all my creative projects with a D codebase. With that said...
• yawniek (16/20) Jan 02 2015 cool stuff, congrats on the progress, i really like it!
• Iain Buclaw via Digitalmars-d (3/8) Jul 04 2014 Good advice that. :)
• Chris (11/50) Jul 08 2014 Very good. That would improve the page a lot.
• BBaz (4/26) Dec 09 2014 What's up with this new website design ?
• Martin Nowak (6/8) Dec 11 2014 Yeah, draft looks good, but this didn't got the priority and
"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
"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
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
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
"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
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
"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
"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
"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
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
"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
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
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:55:03 UTC, David Gileadi wrote:
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
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
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
"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.

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
"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
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 Apr 2014 13:00, "Lars T. Kyllingstad via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer wrote:
I don't share your opinion that the web site need to be "modern" to
avoid warding off potential adopters. If they are turned off of using a system programming language by a bland (debatable) site look and feel, then I think there was really something else bothering them.
Case in point: http://gcc.gnu.org/
What's wrong with that site? Everything is clear to find and readable.
Apr 20 2014
"Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 20 April 2014 at 08:38:25 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 19 Apr 2014 13:00, "Lars T. Kyllingstad via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer
wrote:
I don't share your opinion that the web site need to be
"modern" to
avoid warding off potential adopters. If they are turned off of using a system programming language by a bland (debatable) site look and feel, then I think there was really something else bothering them.
Case in point: http://gcc.gnu.org/
What's wrong with that site? Everything is clear to find and readable.
There's nothing wrong with it at all! I was agreeing with Steve, not arguing against him. My point was that even though GCC is one of the most popular software development tools in the world, their site, like most of gnu.org, looks a bit... old school. Which is just fine. :)
Apr 20 2014
"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
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
"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
"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
"Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the left-justification seen in the current design. It improves readability and gives opportunities for better information density. I know centred, fixed-width designs are in vogue, but for a documentation project, I would that the gutters instead be turned to more useful purposes. Like documentation. -Wyatt
Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the left-justification seen in the current design. It improves readability and gives opportunities for better information density. I know centred, fixed-width designs are in vogue, but for a documentation project, I would that the gutters instead be turned to more useful purposes. Like documentation. -Wyatt
I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! There is a reason why most editors have "zen mode" which centers your code on a screen. It's easier to read when it's centered and not too wide. Current design has no limitation on line width which (at my resolution) results in ~300 characters wide lines, and it's really unreadable. I would go for a maximum of 120 characters wide lines with content centered on larger monitors. -- Aleksandar
Apr 18 2014
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic
<aleksandar ruzicic.info> wrote:

On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the left-justification seen in the current design. It improves readability and gives opportunities for better information density. I know centred, fixed-width designs are in vogue, but for a documentation project, I would that the gutters instead be turned to more useful purposes. Like documentation. -Wyatt
I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read!
Making something that works like this would be excellent: http://forum.dlang.org/ -Steve
Apr 18 2014
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
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
"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
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
"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
"John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
I _strongly_ suggest any proposed redesign retain the left-justification seen in the current design. It improves readability and gives opportunities for better information density. I know centred, fixed-width designs are in vogue, but for a documentation project, I would that the gutters instead be turned to more useful purposes. Like documentation. -Wyatt
I must respectfully disagree about retaining left justification. I have 27'' monitor with resolution of 2560x1440 and left-aligned websites are really hard to read! There is a reason why most editors have "zen mode" which centers your code on a screen. It's easier to read when it's centered and not too wide. Current design has no limitation on line width which (at my resolution) results in ~300 characters wide lines, and it's really unreadable. I would go for a maximum of 120 characters wide lines with content centered on larger monitors. -- Aleksandar
Or just a little switch in a corner somewhere to change the justification, with a cookie.
Apr 18 2014
"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
That can be easily done (although I wouldn't use cookies) but I would prefer centered layout to be default option.
Apr 19 2014
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
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
"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
"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
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
"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
"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
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
"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
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
=?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
"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
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
"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
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
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
"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
"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
"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
"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
"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
"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
"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
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
"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
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
"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
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
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote:
I must respectfully disagree about retaining left justification.
I have 27'' monitor with resolution of 2560x1440 and left-aligned
websites are really hard to read!
Why does everyone these days seem to forget that windows are resizable? FWIW though, I find *everything* freaking unreadable and barely-usable on a 16:9 - good for media, worthless for computing.
There is a reason why most editors have "zen mode" which centers your
code on a screen. It's easier to read when it's centered and not too
wide.
Current design has no limitation on line width which (at my resolution)
results in ~300 characters wide lines, and it's really unreadable.

I would go for a maximum of 120 characters wide lines with content
centered on larger monitors.
Text justification has nothing to do with maximum line width. "max-width" works perfectly fine with left-justified, too. And left-justified makes it easier to distinguish individual lines, otherwise it's easier to loose your place when reading from one line down to the next line. Plus it does suffer from those inconsistently-sized spaces.
Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 21:34:31 UTC, Nick Sabalausky wrote:
On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote:
I must respectfully disagree about retaining left
justification.
I have 27'' monitor with resolution of 2560x1440 and
left-aligned
websites are really hard to read!
Why does everyone these days seem to forget that windows are resizable? FWIW though, I find *everything* freaking unreadable and barely-usable on a 16:9 - good for media, worthless for computing.
There is a reason why most editors have "zen mode" which
centers your
code on a screen. It's easier to read when it's centered and
not too wide.
Current design has no limitation on line width which (at my
resolution)
results in ~300 characters wide lines, and it's really
I would go for a maximum of 120 characters wide lines with
content
centered on larger monitors.
Text justification has nothing to do with maximum line width. "max-width" works perfectly fine with left-justified, too. And left-justified makes it easier to distinguish individual lines, otherwise it's easier to loose your place when reading from one line down to the next line. Plus it does suffer from those inconsistently-sized spaces.
As I've said in one of previous messages, text will be left-aligned, there is no way I would make it centered. I was talking about layout alignment. I was talking about max-width as a means to keep text readable, as 300 characters per line is really too hard to read. It seems I'll have to implement this design proposal in HTML/CSS to be able to better communicate design decisions.
Apr 19 2014
"Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
I have 27'' monitor with resolution of 2560x1440 and
Yeah, me too...
left-aligned websites are really hard to read!
...so I have no idea what you're even talking about with this statement.
There is a reason why most editors have "zen mode" which
centers your code on a screen. It's easier to read when it's
centered and not too wide.
"most"? I have literally never seen this on any editor ever. But that's beside the point.
Current design has no limitation on line width which (at my
resolution) results in ~300 characters wide lines, and it's
To be clear, I'm not favouring unreadable CPL. I'm specifically against the useless gutters to the left and right that, alone, are each too narrow to be particularly useful. Never mind that they account for roughly half of my screen area. I'm not inclined to support any design with that much wasted space. Oddly enough, Wikipedia's main page gets this right: http://en.wikipedia.org/wiki/Main_Page (Though I admit it doesn't degrade gracefully to more narrow dimensions). If proper aspect ratios hadn't been killed by cheapskate panel manufacturers, we probably wouldn't even be having this discussion. -Wyatt
Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 09:40:53 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
I have 27'' monitor with resolution of 2560x1440 and
Yeah, me too...
left-aligned websites are really hard to read!
...so I have no idea what you're even talking about with this statement.
I have by browser's window maximized and websites with lot of text that are left-aligned are (to me at least) hard to read as I need to move focus from center of the monitor to the left edge, and staring at the angle like that for some time makes my eyes hurt..
There is a reason why most editors have "zen mode" which
centers your code on a screen. It's easier to read when it's
centered and not too wide.
"most"? I have literally never seen this on any editor ever. But that's beside the point.
Sublime Text has this, it's called distraction free mode, there was extension for Komodo IDE too, but I haven't used it for years.
Current design has no limitation on line width which (at my
resolution) results in ~300 characters wide lines, and it's
To be clear, I'm not favouring unreadable CPL. I'm specifically against the useless gutters to the left and right that, alone, are each too narrow to be particularly useful. Never mind that they account for roughly half of my screen area. I'm not inclined to support any design with that much wasted space.
I'll try to use as much space as possible. I've said in one of previous messages that extra screen space can (and will) be used for displaying additional content.
Oddly enough, Wikipedia's main page gets this right:
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
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
"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
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
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
"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
"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
"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
"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
"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
"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
"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
"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
"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
"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
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
"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
"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
"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
"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
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.
Apr 22 2014
"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.
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
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/22/2014 4:39 PM, "Ola Fosheim GrÃ¸stad"

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
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/22/14, 1:39 PM, "Ola Fosheim GrÃ¸stad"
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.
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.
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.

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
"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
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 3:13 AM, "Ola Fosheim GrÃ¸stad"
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
"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
"Kagamin" <spam here.lot> writes:
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu
wrote:
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
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:
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
"Dicebot" <public dicebot.lv> writes:
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu
wrote:
... first hit is
-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.

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
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
"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
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
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
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
"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
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
"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
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 8:27 AM, "Ola Fosheim GrÃ¸stad"
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
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
"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
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
"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
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
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
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
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
"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
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
"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
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
"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

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
"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
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
"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
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
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
"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
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
"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
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
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
"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
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 1:53 PM, "Ola Fosheim GrÃ¸stad"
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
"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
"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
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 4:12 PM, "Ola Fosheim GrÃ¸stad"
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
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"

> 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
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
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 2:56 PM, "Ola Fosheim GrÃ¸stad"
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
"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
"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.

primary target is people who stumble over dlang.org while

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

http://www.arngren.net/

It is not because it has wonderful designâ€¦ ;-)
Apr 20 2014
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 20 Apr 2014 03:33:46 -0400, Ola Fosheim Gr=C3=B8stad  =

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
"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
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
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
"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
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
1100110 <0b1100110 gmail.com> writes:
On 4/18/14, 9:04, Aleksandar Ruzicic wrote:
Hello,

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

-- Aleksandar
I REALLY like the new look. I think it's about time to change the website up a little bit for the reasons listed above. It looks 'clean'. Go for it!
Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:
On 4/18/14, 9:04, Aleksandar Ruzicic wrote:
Hello,

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

-- Aleksandar
I REALLY like the new look. I think it's about time to change the website up a little bit for the reasons listed above. It looks 'clean'. Go for it!
Thanks! I'm planning to start working on this as soon as I get approval from Walter/Andrei, and as most of people who answered here are agreed that redesign would be a good thing I hope they wouldn't oppose..
Apr 19 2014
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
"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
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
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
"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
"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
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
"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
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
"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
"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
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
Jacob Carlborg <doob me.com> writes:
On 21/04/14 23:23, Andrei Alexandrescu wrote:

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

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

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

Check out the demo input file

and demo result file

to get an idea of what it does.
Apr 22 2014
"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:

Check out the demo input file

and demo result file

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

Check out the demo input file

and demo result file

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

Check out the demo input file

and demo result file

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
"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
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
"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
"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
"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
"Rikki Cattermole" <alphaglosined gmail.com> writes:
On Thursday, 24 April 2014 at 14:42:44 UTC, Adam D. Ruppe wrote:
On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole
wrote:
Can we have it as a library?
css.d in there has the lib code now with my other html stuff stripped out so it has fewer dependencies. Can dub just use it without using the little main file?
Ugh it can yes. But when you set the target type it definitely cannot. You probably want a dub.json file like this: { "name": "cssexpand", "description": "A CSS expansion program", "authors": ["Adam D. Ruppe"], "homepage": "https://github.com/adamdruppe/cssexpand", "license": "BSL-1.0", "dependencies": { "cssexpand:library": "~master" }, "subPackages": [ { "name": "tool", "dependencies": { "cssexpand:library": "~master" }, "mainSourceFile": "src/cssexpand.d", "targetType": "executable" }, { "name": "library", "sourceFiles": ["src/css.d", "src/color.d"], "targetType": "library" } ] } Defaults a library. To run the tool its basically: dub run cssexpand:tool toolargs... Or you can swap them, up to you.
Note btw that this code is *brutally* slow and should be done
ahead of time or at least aggressively cached; if you
regenerate the file on each request you'll be surprised by how
much cpu time it wastes.
Lets not go into how much javascript code I'm generating in Cmsed ;) So not a worry.
The implementation is pretty much a brute force string search
in a replace loop.
Apr 24 2014
"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
=?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
=?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
"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
"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
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
"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
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
"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
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
"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
Jacob Carlborg <doob me.com> writes:
On 2014-04-22 09:56, "Ola Fosheim GrÃ¸stad"

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
"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
"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
"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
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
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
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
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
"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.
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
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 ;)
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
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
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
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
"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
"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
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
"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
"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
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
"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
"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
"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
"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
"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
Apr 18 2014
"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
improved upon), or search the documentation (which is still a
few clicks away). I'd argue that most people are going for the
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).
page rather than the top nav-bar would be an improvement as
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
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
"Rikki Cattermole" <alphaglosined gmail.com> writes:
On Saturday, 19 April 2014 at 08:16:20 UTC, Aleksandar Ruzicic
wrote:
...
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
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
"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
"Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 21 April 2014 at 11:42:54 UTC, Kagamin wrote:
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
"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:
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
"Martin Nowak" <code dawg.eu> writes:
Different strokes for different folks.
https://github.com/rejectedsoftware/ddox/pull/49
Apr 25 2014
"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
"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
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
Martin Nowak <code dawg.eu> writes:
I have also tried to design something myself (although I'm not a
designer) and this is what I came up with:

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

I'm not entirely satisfied with it but I believe that it looks better
(or at least more modern) than the current design.
This looks great, finally something that doesn't scare off people. Please let me know if you need any help to make this happen.
Apr 22 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 22 April 2014 at 22:24:25 UTC, Martin Nowak wrote:
I have also tried to design something myself (although I'm not
a
designer) and this is what I came up with:

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

I'm not entirely satisfied with it but I believe that it looks
better
(or at least more modern) than the current design.
This looks great, finally something that doesn't scare off people. Please let me know if you need any help to make this happen.
Thanks! I'll be pushing all my work to GitHub from day one (I'll create new branch at https://github.com/raleksandar/dlang.org) so anyone can fork and contribute, later this would be hopefuly merged with official dlang.org repo.
Apr 22 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 04:58:06AM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
Usually when I run into a site with (1) microscopic fonts, (2) giant
(often multicolored) fonts, (3) no whitespace, or (4) has more
ads/filler than content, my fingers have an almost instinctual ctrl-W
(close tab) response. Sometimes not even one word registers in my
brain before I move on to the next site.
Incidentally, ugly rainbow text is also why I set my mail client to plaintext-only ages ago.
[...] I've never left terminal-only email clients. :P For a short time at work I put up with webmail, because they didn't tell me pop3 access was available. Boy, that was painful. Then one day I discovered that I can use pop3, and oh the joy! I installed mutt and fetchmail, and from that day on never looked back. Nowadays, it seems that HTML-only mails are getting more common, which is unfortunate. Luckily, there's elinks -dump, which one of these days I'm gonna hook up to my .procmailrc so that I won't ever see HTML mails, ever again. >:-) On Thu, Apr 24, 2014 at 12:27:09PM +0000, via Digitalmars-d wrote:
On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:
I agree. Unfortunately though, browsers haven't always has reasonable
defaults, so people had to work around, so now it's all pretty much
screwed.

Maybe what we need is a CSS for "sane-size-defaults: on;" which would
provide a "reboot" of the whole default font sizes.
The defaults in the original browsers were set a bit large (16px), so Safari decided to set them smaller for a while. That sucked. Nowadays you can just set the scaling of the body to 87.5% of the default and get a reasonable size (14px).
Funny. I find anything below 16pt unreadably small. But then again, I have a 1600x1200 screen. :P Which I run ratpoison on, which means every window is maximized. So my terminals use an 18pt font to get close to an 80-column display. :P
What annoy me the most is non-promotional sites that set the body
font-family to anything but the default sans-serif (which often
happens to be pixel perfect, have good unicode support and is
legible).
TBH, I find this "pixel perfect" obsession to be really silly. It shows that web developers don't understand that what the user sees is NOT what developers see, because browsers come in many sizes and shapes, and users' screens also come in many sizes and shapes. "This site is best viewable in AAAxYYY resolution" is so last century. When are we gonna grow out of that?! On Thu, Apr 24, 2014 at 01:57:32PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
Another thing that kills me about the new "big picture up top,
scroll to gigantic say-nothing text below" fad....

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

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

<a href="this-makes-me-angry-because-it-sux">Hatred.</a>
Yeah I noticed that about recent new sites. But then again, it's more tolerable than the old "jampack every possible marketing slogan you can onto a presumed 640x480 browser window until it's unreadably cluttered" approach, which *still* conveyed basically no information. "Feature-rich" has become one of those meaningless buzzwords that really should be added to this page: http://www.dack.com/web/bullshit.html :-P Along with "innovative", "comprehensive", "powerful", "creative", "cloud", "mature", etc., all of which have lost their meaning from marketing overuse. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Apr 24 2014
"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
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 24.04.2014 17:34, schrieb "Ola Fosheim GrÃ¸stad"
According to the CCS 2.1 standard 1 px == 0.75pt.

http://www.w3.org/TR/CSS21/syndata.html#length-units

Thus:

16pt => 12px => 3.1mm at a reading distance of 71 cm.
16pt => 21.3px
Apr 24 2014
"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"
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
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 03:59:17PM +0000, via Digitalmars-d wrote:
On Thursday, 24 April 2014 at 15:55:36 UTC, Sönke Ludwig wrote:
Am 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad"
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
Is this still happening? Is there a repo or a place I can go to
help?
May 06 2014
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
"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
"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
"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
"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
"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
"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
"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
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
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
"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
"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
"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
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
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
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
"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
"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
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
"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.

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
=?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
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
"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
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
"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
* 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.

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

I reckon there are clever things I can do with diet to generate
it. Something like this...

- import dlang.toc;

append content
...

...

append extra-sidebar
- toc();

I bet I can make this syntax possible.

Out for now.
Jun 01 2014
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
"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
"w0rp" <devw0rp gmail.com> writes:
https://github.com/w0rp/new-dlang.org/blob/master/src/dlang/toc.d

templates.

|!= h2(toc, "anchor", "Title")

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

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

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.
Jun 10 2014
"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
=?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
"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
"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
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
"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
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
=?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
"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
"w0rp" <devw0rp gmail.com> writes:
I thought I'd post an update on this work so I don't leave any

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

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
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
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
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
"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
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
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
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
"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
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
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
"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
"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
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
"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
=?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
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
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
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
"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
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
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
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
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
"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
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
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
"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
"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
"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
"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
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
"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
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
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
=?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
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 10 Jun 2014 10:06:57 -0400, Andrei Alexandrescu  =

<SeeWebsiteForEmail erdani.org> wrote:

On 6/10/14, 3:42 AM, S=C3=B6nke Ludwig wrote:
* Are there any other opinions on this? I remember that there have be=
en
some strong proponents of using DDOC for things, so it would be bad i=
f
in the end Markdown were to be dropped, after all of the work has
already been done. Personally I'd strongly favor Markdown, though.
I think ddoc is a lot more flexible than markdown, and I'm baffled by =
=
the claim that ddoc is difficult to learn. That said I do agree it's a=
=
turnoff for first-time website contributors. IMHO if we switch away fr=
om =
ddoc we should switch to something better, not something just differen=
t. Markdown can be instantly understood by anyone who sees it. DDOC require= s = lookup/learning, even if you know how DDOC works, you still have to figu= re = out what all the macros mean and do. And none of that is documented as f= ar = as I know. Flexibility isn't everything. The goal is to make it easy to be an autho= r. -Steve
Jun 10 2014
"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
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
"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
"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
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
"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
"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
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
"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
"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
"w0rp" <devw0rp gmail.com> writes:
On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:
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
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
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
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 Jul 2014 20:45, "Alix Pexton via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On 03/07/2014 6:38 PM, w0rp wrote:

* Run it all with D to tick a "official D site made in D" checkbox.
The "powered by Python" banner gave me an idea... In a nod to Walter's self confessed petrol-headedness, I thought we could
incorporate the logo into a "D under the hood" or "D in the tank" banner for sites and software that utilise or run on D.
Might be a bit over the top for dlang.org though ^^

A...
Jul 03 2014
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:
[â€¦]
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
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:
[â€¦]
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
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:
[â€¦]
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
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
"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:
[â€¦]
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
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
"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
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
"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
"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,

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
"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
"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
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Jul 26, 2014 at 10:54:12PM +0000, w0rp via Digitalmars-d wrote:
http://w0rp.com:8010/library/index.html

I just updated the site hosted there with the work I've done on
integrating the library documentation to date. I spent a lot of time
staring at the pages for a while trying to figure out how to fit
everything on a page decent. I admit to hacking the std.algoritm
tables into not being tables, etc. I would very much appreciate any
pull requests which improve on what I've done so far with it. It's all
on GitHub in the usual place.
What do you think about using tables for the functions under each category (e.g. under "searching" in std.algorithm)? Currently it looks like a random scattering of words, and it's quite confusing to look for a particular symbol. A left-justified multi-column layout would be much better IMHO.
https://github.com/w0rp/new-dlang.org
[...] I'll keep that in mind for when I have a bit more time; currently I'm rather swamped and probably won't have time to submit PRs. T -- Computers aren't intelligent; they only think they are.
Jul 26 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 27 July 2014 at 00:43:41 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, Jul 26, 2014 at 10:54:12PM +0000, w0rp via
Digitalmars-d wrote:
http://w0rp.com:8010/library/index.html

I just updated the site hosted there with the work I've done on
integrating the library documentation to date. I spent a lot
of time
staring at the pages for a while trying to figure out how to
fit
everything on a page decent. I admit to hacking the
std.algoritm
tables into not being tables, etc. I would very much
appreciate any
pull requests which improve on what I've done so far with it.
It's all
on GitHub in the usual place.
What do you think about using tables for the functions under each category (e.g. under "searching" in std.algorithm)? Currently it looks like a random scattering of words, and it's quite confusing to look for a particular symbol. A left-justified multi-column layout would be much better IMHO.
The std.algortihm documentation doesn't look good, and I don't have any good ideas for it.
Jul 26 2014
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
"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
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
"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
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
=?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
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
=?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
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
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
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
=?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.

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

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
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
"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
"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
=?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:

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
"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
"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
"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
"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
"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
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
"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
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
On Monday, 28 July 2014 at 08:30:05 UTC, w0rp wrote:
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
"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
"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
"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
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
"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
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
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
"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
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jul 28, 2014 at 09:58:59AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/28/14, 12:29 AM, Gary Willoughby wrote:
I am contributing but you are completely ignoring me and attacking
what i'm saying. I've been a professional web application developer
for years and have a lot of experience with design and UX. Everybody
here is completely ignoring that fact! You don't even understand
branding. So what's the point of me trying to contribute?
Your hostile tone may have contributed to that reaction, however justified your arguments may have been. Coming into a volunteer project and telling people things like "this is garbage", "this is amateurish", "you should stop", "you don't understand anything at all", is very hostile, and therefore likely to provoke a negative reaction, even if the work concerned actually *is* garbage, amateurish, etc.. As Andrei said (quoted below), if instead of tearing others' (voluntary!) work into pieces, you produce a superior piece of work and show it (even if it's just a concept sketch of the end result, not the actual implementation), it will be much more convincing, and people will be much more likely to listen to you. As they say, "show, don't tell".
I've been in similar situations in the past so I sympathize. The one
thing I noticed gets the point across is to just do good work and just
show it.  People otherwise ignorant of what goes into a piece of work
_can_ often appreciate a compelling end result.
[...] T -- Many open minds should be closed for repairs. -- K5 user
Jul 28 2014
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
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
=?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
"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
=?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
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?

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

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

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

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

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
"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.
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
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
half-width is a killer feature over D's current web docs,
especially on desktops without workspaces.
Jul 30 2014
"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
"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
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
"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
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
ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 21 Aug 2014 12:09:37 +0000
Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

It probably looks good as a landing page for a newcomers but I=20
will annoyed with extra forced navigation very quick through=20
daily usage of the web site. It sacrifices productivity in favor=20
of good looks.
exactly what i wanted to say, but cannot find the appropriate words!
Aug 21 2014
"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
"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
"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
"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
"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
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
"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
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
"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
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
=?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
"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
=?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
"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
=?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
Matt Soucy <msoucy csh.rit.edu> writes:
On 08/21/2014 01:37 PM, "Th=C3=A9o Bueno" <munrek gmx.com>" wrote:
On Thursday, 21 August 2014 at 17:31:45 UTC, Dicebot wrote:
On Thursday, 21 August 2014 at 17:24:28 UTC, Th=C3=A9o Bueno wrote:
Also please avoid personal insults :P
I wasn't insulting, my intention was to mention the fact that this argument is not entirely a matter of productivity, but a fear of change.
I was referring to "Don't forget that programmers are hipsters" statem=
ent ;)
=20
Oh. Let me rephrase :
Don't forget that programmers are undeclared hipsters :D
Duck hipstering - if it looks like a hipster, acts like a hipster...it wa= s a hipster before it was cool. Stop declaring your hipsters as "auto" :P= --=20 Matt Soucy http://msoucy.me/
Aug 23 2014
=?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
ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 21 Aug 2014 17:12:37 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

Don't forget that programmers are hipsters, and we need to take
care of our image.
i'm glad that i'm not a programmer then.
Aug 21 2014
"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
"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
"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
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
"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
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
Matt Soucy <msoucy csh.rit.edu> writes:
On 08/21/2014 12:59 AM, Hubert wrote:
First I wanna say that I've become a huge fan of D, and I hope one day =
I can replace all my creative projects with a D codebase. With that said,= I do agree that D could use a redesign. I've not been monitoring this th= read very closely, but the design suggestions I've seen so far has dissap= ointed me. Don't misunderstand me; the proposals look good, but they are = in my opinion too conservative.
=20
Now I've given it a shot and created a first draft on how I imagine a f=
uture Dlang.org could/should look like, keep in mind that nothing is fina= l yet:
=20
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png
=20
My emphasis has been on creating a friendly first impression; a lightwe=
ight page to introduce newcomers to D and get them started quickly. I thi= nk this is a sane design approach when it comes to D's current position i= n the "market". I've not yet begun any work on the views for the document= ation and similar pages with a larger amount of copy.
=20
(I hope I haven't missed any earlier design proposal that already looks=
like this.)
=20
=20
It reminds me a lot of http://zeromq.org/, which is TOLERABLE not not, in= my opinion, great. --=20 Matt Soucy http://msoucy.me/
Aug 23 2014
"yawniek" <dlang srtnwz.com> writes:
On Monday, 28 July 2014 at 22:04:45 UTC, w0rp wrote:
On Sunday, 27 July 2014 at 16:32:15 UTC, SÃ¶nke Ludwig wrote:
Am 27.07.2014 00:54, schrieb w0rp:
You can see some running examples on the site now.

http://w0rp.com:8010/library/std.parallelism/
cool stuff, congrats on the progress, i really like it! from a usability perspective i have two suggestions: 1) re-add the alphabetic list of classes, functions etc, either on top or better in a sidebar as e.g. ruby has it: http://ruby-doc.org/core-2.2.0/String.html it helps a lot if you are new and want to get a quick overview whats possible within a given module. 2) currently clicking on a function name opens a new site with the doc of that function. why not load it inline in a collapsable fragment? (could also be a simple + button that allows this in addition to the link) this would greatly help when quickly going trough a number of functions in a module. cheers y
Jan 02 2015
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 Jul 2014 08:40, "Russel Winder via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
[=E2=80=A6]
SarcasticRover is telling us "Do not come to Mars." Perhaps its commentary need censoring ;-)
Jul 04 2014
"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:
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
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
"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
"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
"Martin Nowak" <code dawg.eu> writes:
On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:
Already submitted a bunch of pulls.
https://github.com/D-Programming-Language/dlang.org/pulls?q=is%3Apr+author%3AMartinNowak+is%3Aclosed I'd be thankful for any help on that. Cloning dlang.org and running make -f posix.mak should work currently, so it's easy to try out ideas.
Dec 11 2014
=?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:
What's up with this new website design ?
Drafts looked good.
Yeah, draft looks good, but this didn't got the priority and support it deserves.