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/
- Iain Buclaw via Digitalmars-d (6/10) Apr 20 2014 avoid warding off potential adopters. If they are turned off of using a
- Lars T. Kyllingstad (7/25) Apr 20 2014 There's nothing wrong with it at all! I was agreeing with Steve,
- 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:
- Nick Sabalausky (5/12) Apr 19 2014 God no. I like forum.dlang.org and all, but scaling the font size when
- Jacob Carlborg (4/8) Apr 20 2014 I haven't noticed that until now. That truly sucks.
- Steven Schveighoffer (11/26) Apr 21 2014 I like how the side-bar goes away instead of making the text column
- Nick Sabalausky (11/16) Apr 21 2014 I don't. Overly-large text is just as hard to read as overly-small text.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/7) Apr 21 2014 Then again, most users don't even know that there is a search
- 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?
- Aleksandar Ruzicic (8/40) Apr 19 2014 As I've said in one of previous messages, text will be
- 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
- Aleksandar Ruzicic (5/11) Apr 18 2014 I completely agree with this. There is a website I work on from
- Nick Sabalausky (14/23) Apr 19 2014 On a philosophical level, I *very* strongly disagree with this as I
- Andrej Mitrovic via Digitalmars-d (5/8) Apr 19 2014 Yep. Also see how often MSDN breaks their links to their docs. Not
- 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
- Aleksandar Ruzicic (10/25) Apr 18 2014 I was aiming for something that will communicate "this is a
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (16/19) Apr 18 2014 In the past decade there has been so many startups with
- Aleksandar Ruzicic (13/32) Apr 18 2014 I really like rust-lang.org, I was thinking of using it as a base
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (16/22) Apr 18 2014 :-) I like rust-lang for being concise and outspoken about what
- Kagamin (14/19) Apr 21 2014 This navigation layout was used for centuries in paper books.
- Aleksandar Ruzicic (7/27) Apr 21 2014 Sidebar can be hidden by use of @media queries as the window
- Andrei Alexandrescu (4/14) Apr 21 2014 Wait, are you advocating for text occupying the entire page width, like
- Aleksandar Ruzicic (8/31) Apr 21 2014 Yes, there were numerous studies about line length (I don't have
- Lars T. Kyllingstad (9/15) Apr 22 2014 This isn't specific to the web. The typographic rules about line
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (22/24) Apr 22 2014 Yeah, well, but the truth is that there is no solid truths
- Kagamin (5/8) Apr 22 2014 What's problem with entire page width? I don't remember
- Andrei Alexandrescu (3/10) Apr 22 2014 https://www.google.com/search?q=page%20width%20study#q=optimal+page+widt...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (20/28) Apr 22 2014 As I have already pointed out, there is no optimal width. E.g. if
- Nick Sabalausky (7/9) Apr 22 2014 Man do I REALLY wish movie makers and game devs would at least TRY to
- Andrei Alexandrescu (12/39) Apr 22 2014 According to the top hits in the search I posted, your point is not vali...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (39/46) Apr 23 2014 You don't understand that it is offensive to respond to an
- Andrei Alexandrescu (4/11) Apr 23 2014 As a project maintainer I try to foster good exchange of information. I
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/12) Apr 23 2014 In most contexts that will be taken as a RTFM response, as in:
- Kagamin (4/5) Apr 23 2014 The first link say 100 characters per line. If 100 characters
- Andrei Alexandrescu (35/40) Apr 23 2014 Maybe Google personalized my search, but the first hit is
- Dicebot (9/34) Apr 23 2014 Gosh now I finally know what researches to blame for my eyes
- Andrei Alexandrescu (2/8) Apr 23 2014 I don't know. It's a good question and an interesting challenge. -- Andr...
- H. S. Teoh via Digitalmars-d (12/18) Apr 23 2014 On the contrary, I find almost all websites have broken layouts because
- Walter Bright (12/15) Apr 23 2014 This is why teams need some old codgers like me around. We don't see so ...
- Nick Sabalausky (6/17) Apr 23 2014 I certainly won't disagree that small fonts can be hard to read, but on
- H. S. Teoh via Digitalmars-d (30/52) Apr 23 2014 I can still see relatively well, but I prefer not having to squint at
- Nick Sabalausky (27/51) Apr 24 2014 Ugh, actually I wish I had some. I tend to run away from those sites too...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (9/14) Apr 24 2014 The defaults in the original browsers were set a bit large
- Nick Sabalausky (3/6) Apr 24 2014 Yea, I've seen some web documents written in really hard-to-read fonts.
- Walter Bright (4/5) Apr 24 2014 I've recently seen some academic research PDF's where the font is so sma...
- bearophile (9/14) Apr 24 2014 Some combinations of PDF readers and PDF files support reflow, so
- H. S. Teoh via Digitalmars-d (11/25) Apr 24 2014 I don't like wide screens that much, actually. I still prefer 4x3 aspect
- Nick Sabalausky (5/8) Apr 24 2014 I've even seen companies actually trying to sell ~2:1 abominations. Even...
- Walter Bright (2/5) Apr 24 2014 Wider ones won't help. You'd need a taller one.
- Nick Sabalausky (5/10) Apr 24 2014 Don't they write them in Latex and then generate the PDF? You'd think
- H. S. Teoh via Digitalmars-d (17/31) Apr 24 2014 True. In theory, you could make your LaTeX document flexible enough to
- Nick Sabalausky (4/8) Apr 24 2014 I would think basic computing features like text editing, copy/paste,
- H. S. Teoh via Digitalmars-d (34/45) Apr 24 2014 True, it's quite easy in LaTeX to split your document into multiple
- Nick Sabalausky (18/30) Apr 25 2014 Actually, I just meant:
- Adam D. Ruppe (8/8) Apr 24 2014 Another thing that kills me about the new "big picture up top,
- Kagamin (10/25) Apr 24 2014 I use semantic markup for emphasis where it's supported. Can't
- Nick Sabalausky (10/24) Apr 24 2014 Markdown:
- Kagamin (8/20) Apr 25 2014 That looks like semantic markup. Visual markup would be
- Gary Willoughby (3/8) Apr 23 2014 Javascript libraries fill this gap:
- Alix Pexton (4/6) Apr 24 2014 Are you sure that your eyes aren't bleeding because your fonts are too
- Dicebot (5/12) Apr 24 2014 Considering the very same size 9 fonts are used as default
- Alix Pexton (10/14) Apr 24 2014 We must just be oppositesAt the distance I sit from my monitor 9pt type
- H. S. Teoh via Digitalmars-d (14/32) Apr 24 2014 I find it disappointing that after so many decades, we still haven't
- Nick Sabalausky (3/7) Apr 24 2014 That's exactly how HTML used to work, but then the print folk and
- Alix Pexton (20/24) Apr 24 2014 We must just be opposites.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (11/19) Apr 23 2014 At some point you'll probably realize that the term "cpl" is not
- Andrei Alexandrescu (8/30) Apr 23 2014 I'm talking averages.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (20/31) Apr 24 2014 It varies with the font used. :-P And if you use a webfont the
- Kagamin (13/21) Apr 25 2014 If the sidebar is not critical, then maybe get rid of it, why
- Nick Sabalausky (18/25) Apr 19 2014 Good points.
- Nick Sabalausky (6/13) Apr 19 2014 One very notable downside of this style is that it pretty much requires
- Nick Sabalausky (17/20) Apr 19 2014 I had a brief thought of that too, but I quickly dismissed it because it...
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (18/23) Apr 20 2014 To me it looks like a typical start-up design. It does not peek
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (14/14) Apr 20 2014 Just to stating some basic observations to avoid noise.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (28/28) Apr 20 2014 I just had a non-alcohol beer, so I think I'll rant some more
- Steven Schveighoffer (5/6) Apr 21 2014 Sorry, don't take this the wrong way, it's my OCD, not your fault ;)
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (9/12) Apr 21 2014 Of course it is my fault! I always thought it was "peak", thanks
- Nick Sabalausky (15/21) Apr 18 2014 I'm normally very skeptical and critical of "staying modern" (and
- Nick Sabalausky (4/5) Apr 18 2014 [...]
- Aleksandar Ruzicic (8/39) Apr 19 2014 I was told you would oppose usage of JavaScript. :)
- Nick Sabalausky (7/30) Apr 19 2014 Heh, yea, I'm kinda well-known for that 'round these parts ;)
- 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
- Rikki Cattermole (3/16) Apr 23 2014 Okay, doesn't look too bad of a deal that.
- 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?
- Adam D. Ruppe (11/12) Apr 24 2014 css.d in there has the lib code now with my other html stuff
- Rikki Cattermole (34/46) Apr 24 2014 Ugh it can yes. But when you set the target type it definitely
- Adam D. Ruppe (3/4) Apr 24 2014 I added the configurations Sonke suggested, see if it works now.
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (13/18) Apr 24 2014 This should automatically yield two configurations - "application" and
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (24/35) Apr 24 2014 Meh, unfortunately it requires to add the tow configurations manually:
- 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:
- Jacob Carlborg (4/7) Apr 22 2014 What's fucked up with the links?
- Nick Sabalausky (21/28) Apr 23 2014 They don't work.
- H. S. Teoh via Digitalmars-d (31/43) Apr 23 2014 [...]
- Nick Sabalausky (49/69) Apr 24 2014 (Argh! Accidentally emailed this to digitalmars-d@puremagic.com twice!
- Jacob Carlborg (11/31) Apr 23 2014 Yes. Bootstrap won't touch your links with JavaScript, unless you tell
- Martin Nowak (2/5) Apr 22 2014 Nick what are you talking about? They referenced some anchors in
- 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.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (10/13) Apr 22 2014 You can do all the quantitative laboratory experiments in the
- Jacob Carlborg (8/28) Apr 22 2014 I say it's the opposite. I never use plain CSS or JavaScript these days....
- 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 [...]
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (30/91) Apr 24 2014 According to the CCS 2.1 standard 1 px == 0.75pt.
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (3/7) Apr 24 2014 16pt => 21.3px
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/13) Apr 24 2014 Yeah, I thought it was a bit odd, it sounded more like 9pt. I
- H. S. Teoh via Digitalmars-d (10/25) Apr 24 2014 I like my fonts nice and big. It's just me. :)
- 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,
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (13/32) Jun 01 2014 I thought there was a ticket open to let Diet templates automatically
- 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
- Iain Buclaw via Digitalmars-d (8/41) Jul 01 2014 By the way, did you get round to implementing some sort of generic
- w0rp (7/15) Jul 01 2014 I did not. We are defintely writing very similar things, so if
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (9/52) Jul 01 2014 If it works with libevent and could be fit into this API:
- Iain Buclaw via Digitalmars-d (10/76) Jul 01 2014 It doesn't use libevent... yet. As I said, its bashed together so
- Brad Anderson (2/36) Jul 01 2014 I did that a couple years ago: http://goo.gl/trMh6k
- 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/9) Jun 10 2014 Something better/more powerful would be something backed by a proper
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (11/21) Jun 10 2014 Markdown has the advantages of a semantic content representation - so
- Steven Schveighoffer (18/27) Jun 10 2014 en
- Dicebot (7/13) Jun 10 2014 This. I use DDOC for actual documentation daily and still was
- Jacob Carlborg (5/10) Jun 10 2014 Can the templates be compiled in a separate phase, not using CTFE but as...
- 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
- Dicebot (2/6) Jul 26 2014
- 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
- w0rp (14/37) Jul 27 2014 To display more appropriate content for two different screen
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (24/32) Jul 28 2014 I think you should represent the information once. Otherwise
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/6) Jul 28 2014 (You might also run into SEO problems, getting a reduced ranking
- 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
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (15/18) Jul 28 2014 You need to define and agree on a process first. If not you will
- Gary Willoughby (3/21) Jul 28 2014 At last somebody else who understands.
- Dicebot (10/28) Jul 28 2014 It has never worked that way with D development process and I
- 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
- Dicebot (5/17) Aug 21 2014 I prefer to have my cake and eat it at the same time. There is no
- =?UTF-8?B?IlRow6lv?= Bueno" (5/9) Aug 21 2014 I wasn't insulting, my intention was to mention the fact that
- Dicebot (3/7) Aug 21 2014 I was referring to "Don't forget that programmers are hipsters"
- =?UTF-8?B?IlRow6lv?= Bueno" (3/11) Aug 21 2014 Oh. Let me rephrase :
- Matt Soucy (7/19) Aug 23 2014 Duck hipstering - if it looks like a hipster, acts like a hipster...it w...
- =?UTF-8?B?IlRow6lv?= Bueno" (7/10) Aug 21 2014 Also, please see this message :
- ketmar via Digitalmars-d (3/5) Aug 21 2014 i'm glad that i'm not a programmer then.
- 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
- Martin Nowak (5/6) Dec 11 2014 https://github.com/D-Programming-Language/dlang.org/pulls?q=is%3Apr+auth...
- =?UTF-8?B?IlRow6lv?= Bueno" (2/6) Jan 01 2015 So, is it dead already ?
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
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: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.orgHello, 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, 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
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu wrote:On 4/18/14, 8:30 AM, David Gileadi wrote:I think that having vibe.d behind dlang.org would be great!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
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu wrote:On 4/18/14, 8:30 AM, David Gileadi wrote: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.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
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
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu wrote:On 4/18/14, 8:30 AM, David Gileadi wrote:Going the vibe.d route would be great for advertising D as an all encompassing language.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 21 2014
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:Phew...you narrowly avoided a Nick/Teoh JS rant there :P.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).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.comAlso 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?
Apr 18 2014
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.comThanks! 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]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]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?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.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. :)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
On Friday, 18 April 2014 at 16:55:03 UTC, David Gileadi wrote:If you have access to real designers (as you mentioned in another message) that would be fantastic. I think the mockup you created is already a good direction but folks with experience in UX, typography, responsive design etc. could probably make dlang.org properly great.I just need to motivate them somehow. Designers are a bit strange bunch :)I'd be happy to help. My time is more divided nowadays but I'm sure I can put some time into this. While we're at it some good mobile support would be awesome too.Excellent! And responsive design which scales well from desktops to tablets and phones is a must (with support for hdpi screens of course).
Apr 18 2014
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. -SteveThe 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
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:Really? To me it looks like the OP is mimicking Github dccumentation pages. eg: http://uwsgi-docs.readthedocs.org/en/latest/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...
Apr 18 2014
On Friday, 18 April 2014 at 17:20:55 UTC, Iain Buclaw via Digitalmars-d wrote:Really? To me it looks like the OP is mimicking Github dccumentation pages. eg: http://uwsgi-docs.readthedocs.org/en/latest/I really like the look of Read the Docs and it's something I would definitely base design of documentation pages on (which are the most important, in my opinion). But that mockup of homepage is not directly inspired by (or trying to mimic) any website. I've just opened Photoshop chose base colors and made layout that felt natural to me.
Apr 18 2014
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
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: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.I don't share your opinion that the web site need to be "modern" toCase in point: http://gcc.gnu.org/What's wrong with that site? Everything is clear to find and readable.
Apr 20 2014
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: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. :)On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer wrote: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.I don't share your opinion that the web site need to be "modern" toCase in point: http://gcc.gnu.org/What's wrong with that site? Everything is clear to find and readable.
Apr 20 2014
"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
On 2014-04-18 09:04, Aleksandar Ruzicic wrote:So, what do you guys think?i like it.
Apr 18 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? -- AleksandarI 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
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
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
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: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. -- AleksandarSo, 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
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:Making something that works like this would be excellent: http://forum.dlang.org/ -SteveOn Friday, 18 April 2014 at 14:04:04 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!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
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: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 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/
Apr 19 2014
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
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: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. -SteveOn Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic <aleksandar ruzicic.info> 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 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/
Apr 21 2014
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
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
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:Or just a little switch in a corner somewhere to change the justification, with a cookie.On Friday, 18 April 2014 at 14:04:04 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. 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. -- AleksandarSo, 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
On Friday, 18 April 2014 at 22:06:03 UTC, John Colvin wrote: [snip]Or just a little switch in a corner somewhere to change the justification, with a cookie.That can be easily done (although I wouldn't use cookies) but I would prefer centered layout to be default option.
Apr 19 2014
On 4/19/2014 3:45 AM, Aleksandar Ruzicic wrote:On Friday, 18 April 2014 at 22:06:03 UTC, John Colvin wrote: [snip](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).Or just a little switch in a corner somewhere to change the justification, with a cookie.That can be easily done (although I wouldn't use cookies) but I would prefer centered layout to be default option.
Apr 19 2014
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
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: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 :)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
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
On Saturday, 19 April 2014 at 10:23:39 UTC, Jacob Carlborg wrote:On 2014-04-19 10:54, Aleksandar Ruzicic wrote: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..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
Apr 19 2014
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
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
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: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.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
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
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
On Saturday, 19 April 2014 at 12:04:11 UTC, Sönke Ludwig wrote:Am 19.04.2014 12:56, schrieb Aleksandar Ruzicic:That's excellent news! Would it be possible to use it to search through language reference too?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
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
On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote:OK, I'll work on a design more, I'll also try to have real designers involved to help me with these UX stuff.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.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
On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote:On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:Honestly, I think you're selling yourself short here. You appear to have a pretty good eye for design.- 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.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.- A *lot* of search boxes on the internet these days bake the "Enter search term here" (or whatever) text into the HTML, forcing non-JS users to delete the text before they're able to enter their search term. That's bad UX. Instead, the "Enter search term here" text should be *added* via JS and left blank in the raw HTML. That's a trivial way to ensure it works great for both JS and non-JS users.Nowdays there is something called placeholder attribute[1] on input elements that servers just for that purpose (text goes away as soon as you start typing) and there is no JS needed for that as it is supported by all major browsers. But I like to add fallback (that works even without JS, but better with JS) for that on old browsers which don't support that feature. [1] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms_in_HTML#The_placeholder_attribute
Apr 19 2014
On Saturday, 19 April 2014 at 23:10:58 UTC, Nick Sabalausky wrote:On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote: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.. :)On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:Honestly, I think you're selling yourself short here. You appear to have a pretty good eye for design.- 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.[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
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
On Wednesday, 23 April 2014 at 07:16:53 UTC, Martin Nowak wrote: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..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
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
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:Yep, that's how I plan to do it. First just to redesign the complete website then to add features like search suggestions.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.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.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
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
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 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).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?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.[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
On 4/19/2014 7:48 AM, Kagamin wrote:On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: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.[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
On Saturday, 19 April 2014 at 21:49:20 UTC, Nick Sabalausky wrote:On 4/19/2014 7:48 AM, Kagamin wrote: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 :)On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote: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.[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
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
On Saturday, 19 April 2014 at 23:06:55 UTC, Nick Sabalausky wrote:On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote: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..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
On 4/19/2014 7:19 PM, Aleksandar Ruzicic wrote:On Saturday, 19 April 2014 at 23:06:55 UTC, Nick Sabalausky wrote: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.On 4/19/2014 6:01 PM, Aleksandar Ruzicic wrote: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.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
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 toowide.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
On Saturday, 19 April 2014 at 21:34:31 UTC, Nick Sabalausky wrote:On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote: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.I must respectfully disagree about retaining leftjustification.I have 27'' monitor with resolution of 2560x1440 andleft-alignedwebsites 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" whichcenters yourcode on a screen. It's easier to read when it's centered andnot too wide.Current design has no limitation on line width which (at myresolution)results in ~300 characters wide lines, and it's reallyunreadable.I would go for a maximum of 120 characters wide lines withcontentcentered 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
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote:I have 27'' monitor with resolution of 2560x1440 andYeah, me too...left-aligned websites are really hard to read!...so I have no idea what you're even talking about with this statement.There is a reason why most editors have "zen mode" which centers your code on a screen. It's easier to read when it's centered and not too wide."most"? I have literally never seen this on any editor ever. But that's beside the point.Current design has no limitation on line width which (at my resolution) results in ~300 characters wide lines, and it's really unreadable.To be clear, I'm not favouring unreadable CPL. I'm specifically against the useless gutters to the left and right that, alone, are each too narrow to be particularly useful. Never mind that they account for roughly half of my screen area. I'm not inclined to support any design with that much wasted space. Oddly enough, Wikipedia's main page gets this right: http://en.wikipedia.org/wiki/Main_Page (Though I admit it doesn't degrade gracefully to more narrow dimensions). If proper aspect ratios hadn't been killed by cheapskate panel manufacturers, we probably wouldn't even be having this discussion. -Wyatt
Apr 21 2014
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 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..I have 27'' monitor with resolution of 2560x1440 andYeah, me too...left-aligned websites are really hard to read!...so I have no idea what you're even talking about with this statement.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.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.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.Current design has no limitation on line width which (at my resolution) results in ~300 characters wide lines, and it's really unreadable.To be clear, I'm not favouring unreadable CPL. I'm specifically against the useless gutters to the left and right that, alone, are each too narrow to be particularly useful. Never mind that they account for roughly half of my screen area. I'm not inclined to support any design with that much wasted space.Oddly enough, Wikipedia's main page gets this right: http://en.wikipedia.org/wiki/Main_Page (Though I admit it doesn't degrade gracefully to more narrow dimensions).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. -WyattAgreed. :)
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
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
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
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
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
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote:http://krcko.net/dlang.org/dlang-home-draft1.pngIsn'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
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: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)..http://krcko.net/dlang.org/dlang-home-draft1.pngIsn'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
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
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: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.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
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
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 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.netI 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
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
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
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: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).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).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).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
On 4/21/14, 5:01 AM, Kagamin wrote:On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic 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? -- AndreiI 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).
Apr 21 2014
On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu wrote:On 4/21/14, 5:01 AM, Kagamin 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.On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic 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? -- AndreiI 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).
Apr 21 2014
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
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
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? -- AndreiWhat'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
On 4/22/14, 3:32 AM, Kagamin wrote:On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu wrote:https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off AndreiWait, 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? -- AndreiWhat'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
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:On 4/22/14, 3:32 AM, Kagamin wrote: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.)What's problem with entire page width? I don't remember difficulty reading w3c docs or gcc docs or linux man pages even when they occupy the entire page width.https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=off
Apr 22 2014
On 4/22/2014 4:39 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:This is the proper link: http://www.w3.org/TR/WCAG20-TECHS/Man do I REALLY wish movie makers and game devs would at least TRY to follow this one: http://www.w3.org/TR/WCAG20-TECHS/G56.html In just the last decade, it's become absurdly common for dialog to be *quieter* than sound effects and background music. Insane.
Apr 22 2014
On 4/22/14, 1:39 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:According to the top hits in the search I posted, your point is not valid.On 4/22/14, 3:32 AM, Kagamin wrote: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.What's problem with entire page width? I don't remember difficulty reading w3c docs or gcc docs or linux man pages even when they occupy the entire page width.https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=offSo why are you doing this? Trying to be clever? Obviously not.I don't understand the motivation of this quip.Kagamin meant "window width". Clearly if the user can adjust his window he can get the desired text width.Today's crop of browsers are tabbed, and for many users the position of the browser window is dictated by external constraints (relation to other windows, external monitor or not etc) and it's unreasonable to demand resizing the window whenever they swap tabs.Only after two decades of academics pointing out a need for flexible width do web designers get it and start chanting for "responsive design". Not because they actually understand what they are doing, but because they were FORCED to leave their ugly fixed width obsession by the introduction of mobile devices.Strawman. I'm not advocating for fixed width.Too many documentation sites still get this wrong, meaning: they don't work properly if the user sets a larger font or uses his own stylesheets. This is the proper link: http://www.w3.org/TR/WCAG20-TECHS/ (You ARE flame baiting, right? I think you owe Kagamin an apology.)Wut? This is weird, but whatevs. Just please don't charge him attorney fees :o). Andrei
Apr 22 2014
On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu wrote: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.Trying to be clever? Obviously not.I don't understand the motivation of this quip.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
On 4/23/14, 3:13 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu wrote:As a project maintainer I try to foster good exchange of information. I found the link informative. -- AndreiYou 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.Trying to be clever? Obviously not.I don't understand the motivation of this quip.
Apr 23 2014
On Wednesday, 23 April 2014 at 16:13:42 UTC, Andrei Alexandrescu wrote:On 4/23/14, 3:13 AM, "Ola Fosheim Grøstad"In most contexts that will be taken as a RTFM response, as in: «why didn't you search for this yourself?»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
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:https://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=offThe 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
On 4/23/14, 4:30 AM, Kagamin wrote:On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote: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. Andreihttps://www.google.com/search?q=page%20width%20study#q=optimal+page+width+for+reading&safe=offThe 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
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote:... first hit is http://graphicdesign.stackexchange.com/questions/13724/recommended-column-width-for-text-readin -digital-vs-printed pointing to a study indicating 95 characters per line as optimal for on-screen reading comprehension. The subjective preferences, however, was biased toward smaller numbers. The second link is http://baymard.com/blog/line-length-readability which points to a few studies concluding that 50-75 cpl (characters per line) would be indicated for web design. Third is http://stackoverflow.com/questions/7460041/whats-a-good-maximum-width- f-text-on-a-webpage which quotes a really nice collection of numbers from Smashing Magazine from popular websites, showing that 84% of the sites they looked at use 65-104 cpl. It just struck me that Google's own search page that I'm looking at right now, which I vaguely recall did not limit line lengths a few years ago, is now using a 90 cpl limit. The page's right-hand side is a white area. Next is http://webstyleguide.com/wsg3/7-page-design/6-page-width-line-length.html, which mentions 66 cpl as optimal from a physiological standpoint. Next is http://socialtriggers.com/perfect-content-width/ which nicely advocates smaller cpl at the top of the content (so people read the essential message quickly) followed by 100 cpl.Gosh now I finally know what researches to blame for my eyes bleeding upon most web site restylings (Facebook *caugh-caugh*). If anything it just shows that overall reading skills are decreasing and no one care about visitors with small fonts (me). But current HTML/CSS standards don't provide way to express sizes as percentage of screen width (as opposed to page window width), do they?
Apr 23 2014
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
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
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
On 4/23/2014 2:12 PM, Walter Bright wrote:On 4/23/2014 10:02 AM, H. S. Teoh 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.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.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
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: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.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.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.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-devIronically, the most unreadable web pages I've seen were on apple.com. Haven't looked at it recently, but they'd use a tiny font, and make it light gray letters on a white background. It was literally painful to try and read it.Grey-on-white is ridiculously common and should be jailable offense. I'll never understand the the reasoning behind that readability destroyer.
Apr 23 2014
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: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.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.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.From what I've seen, most of those really weird-colored ones were cases where I wouldn't necessarily expect the author to be good with styling. But grey-on-white gets used even by sites that *should* know better. GitHub was pretty bad with that a couple years ago. contrast, so you often want something that's just a really dark grey. But still, a lot of sites take the softened-contrast thing too far.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.
Apr 24 2014
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
On 4/24/2014 8:27 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:What annoy me the most is non-promotional sites that set the body font-family to anything but the default sans-serif (which often happens to be pixel perfect, have good unicode support and is legible).Yea, I've seen some web documents written in really hard-to-read fonts.
Apr 24 2014
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
Walter Bright:I've recently seen some academic research PDF's where the font is so small that even if I go full screen on them they are very hard to read.Some combinations of PDF readers and PDF files support reflow, so later you can also increase the zoom. Another solution is to buy a wider screen, now even wide ones are kind of cheap.I don't get the reason for doing this. Are they trying to save paper or something?They are often trying to save paper. Some conferences (and sometimes even some journals) set a maximum limit of pages for submitted papers. Bye, bearophile
Apr 24 2014
On Fri, Apr 25, 2014 at 01:54:29AM +0000, bearophile via Digitalmars-d wrote:Walter Bright: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. :-PI've recently seen some academic research PDF's where the font is so small that even if I go full screen on them they are very hard to read.Some combinations of PDF readers and PDF files support reflow, so later you can also increase the zoom. Another solution is to buy a wider screen, now even wide ones are kind of cheap.[...] 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 FordI 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.
Apr 24 2014
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. :-PI'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
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
On 4/24/2014 9:54 PM, bearophile wrote:Walter Bright: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.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.
Apr 24 2014
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: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.Walter Bright: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.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.
Apr 24 2014
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
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: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.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
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
Another thing that kills me about the new "big picture up top, scroll to gigantic say-nothing text below" fad.... The text below sounds like there might be some more learning to do. So I try to click on the headers.... nothing happens. No see more link. Apparently "Feature rich: we have more features than anybody!" is all they have to say. No explanation of what those features are. <a href="this-makes-me-angry-because-it-sux">Hatred.</a>
Apr 24 2014
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
On 4/24/2014 9:59 AM, Kagamin wrote:On Thursday, 24 April 2014 at 08:17:15 UTC, Nick Sabalausky wrote:Markdown: *italic* **bold** **_bold and italic_** Although it appears to implement those using <em> and <strong>, which strikes me as completely pointless and roundabout.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.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
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_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.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 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
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
On Thursday, 24 April 2014 at 08:06:18 UTC, Alix Pexton wrote:On 23/04/2014 5:28 PM, 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.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
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
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:Glad to know I'm not the only one! :)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.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
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
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
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
On 4/23/14, 1:53 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote:I'm talking averages.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.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
On Wednesday, 23 April 2014 at 23:25:43 UTC, Andrei Alexandrescu wrote: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. :-]1. you don't use a monofont and have to figure out what "cpl" is in "em" or "rem".I'm talking averages.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…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.3. quantitative human factors studies that go beyond your inate capabilites tend to be full of severe methodological flaws.Uhm...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).Waste of time.I doubt it.
Apr 24 2014
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
On 4/18/2014 4:12 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:1. visitors are likely to be familiar with one of those 2. they might have figured out something that works 3. you want to do at least what they do, but betterGood 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
On 4/19/2014 6:52 PM, Nick Sabalausky wrote:On 4/18/2014 4:12 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote: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.> 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
On 4/18/2014 2:56 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:Nice initiative, but the top bar looks a lot like adobe.com . I think something less corporate would be more suitable. What are you trying to communicate? A community or a corporation?I had a brief thought of that too, but I quickly dismissed it because it really *isn't* corporate-looking... I swear I'm not joking about this: *Real* corporate sites are: 1. Covered with obviously-stock photos of evenly-distributed easily-identifiable ethnicities (nothing mixed or ethnicly-ambiguous), with 50%/50%/0% gender ratio (if anything, biased towards black females with 90's "hip" curly-poofy hairstyles), all in suits with unrealistically gigantic "Gosh I *LOVE* working in IT and/or customer support call center" smiles. 2. *All* the text across the entire page is completely vacuous, highly subjective *at best*, and generally carries no real meaning whatsoever. So while there are some corporate-like elements (flat shading, clean straight lines, limited saturated-colors palette - all of which are just as "modern" as they are "corporate") this mockup, overall, is definitely *not* very corporate-looking IMO.
Apr 19 2014
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
Just to stating some basic observations to avoid noise. 1. Graphic design of frontpages should follow the principle: "form follows function". 2. Mimicry of the visual style used on adobe.com will make you look good, and somehow familiar, but it is not going to make you stand out. 3. The current D population is not your primary target. Your primary target is people who stumble over dlang.org while searching on Google and spend 2 seconds glancing over your stuff. 4. You need to communicate effectively before they move on. Peek their interest. Create enough curiosity to sell them your main points. Looking good is great, but subordinate to peaking curiosity and reflecting that you have something unique to sell.
Apr 20 2014
I just had a non-alcohol beer, so I think I'll rant some more while I'm at it: WHY don't the community front the story of Walter Bright's D vision on the front-page? It is a wonderful selling point that appeals to geeks and make them interested: 1. Competent: Wrote a well known C++ compiler 2. Shared vision: Created D out of frustration with C++ 3. Exciting: performance is key 4. Motives: Altruistic 5. A-political: open source, commercial friendly and international 6. Has a following: active community, community driven 7. Jump in: Open to participation The current front page is too anonymous to make me interested. The original (long time ago) website was more personal and there was a sense of "personal drive" to it. It gave me a "Dang, that's cool. That Walter dude is brave enough to take on C++. Gotta see what this is all about." feeling. A personal design with a personal vision is more attractive to me than a "professional design" (which actually is just a fashion statement) with longwinded descriptions that lacks focus (nobody actually read those, they want to see code samples). Not to say that there is a right or wrong way to go about web site design, and a blend of the various approaches is probably the right thing. As an example I'll point out that this norwegian site has a very good ranking at Google: http://www.arngren.net/ It is not because it has wonderful design… ;-)
Apr 20 2014
On Sun, 20 Apr 2014 03:33:46 -0400, Ola Fosheim Gr=C3=B8stad = <ola.fosheim.grostad+dlang gmail.com> wrote:It does not peek my interestSorry, don't take this the wrong way, it's my OCD, not your fault ;) But it's "pique" -Steve
Apr 21 2014
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
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
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
On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote:On 4/18/2014 10:04 AM, Aleksandar Ruzicic wrote:Of course.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)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
On 4/19/2014 3:48 AM, Aleksandar Ruzicic wrote:On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote:Cool.As long as it's: - A normal reflowing layout (not a static fixed-width one or an auto-rescaling one)Of course.Heh, yea, I'm kinda well-known for that 'round these parts ;)- 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.Yea, that's cool. Honestly, even I do that too.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 ;)- 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
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? -- AleksandarI 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
On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:On 4/18/14, 9:04, Aleksandar Ruzicic wrote: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..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? -- AleksandarI 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 19 2014
On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote:On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 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.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
On Saturday, 19 April 2014 at 23:21:15 UTC, Nick Sabalausky wrote:On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote: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. :)On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 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.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
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
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
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote:On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:Great! I'll start tonight! :)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 21 2014
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote:On 4/19/14, 1:02 AM, 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..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 21 2014
On 4/21/14, 8:48 AM, Aleksandar Ruzicic wrote:On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote: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.On 4/19/14, 1:02 AM, 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?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! -- AndreiAs 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
On Monday, 21 April 2014 at 18:35:04 UTC, Andrei Alexandrescu wrote:On 4/21/14, 8:48 AM, Aleksandar Ruzicic wrote:Understood.On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote: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.On 4/19/14, 1:02 AM, 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?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! -- AndreiI'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)..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
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
On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:Yep, forgot to mention that libsass (used by node-sass) is cross-platform C library. Thanks!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
On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote: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-browserifyI'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
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
On 21/04/14 23:23, Andrei Alexandrescu wrote:I confess getting a bit uncomfortable about adding new dependencies at this point. We depend on dpl-docs already, and the tool was difficult to install and broke from one dmd release to the next. Sönke was nice and proactive about it, but he's an active member of the community. If we find issues with tooling coming from the outside - and we will - we're on our own. It would help if many people in the community are fluent with them.I've used Sass a lot. Although not via node.Adding a tool right now that has overlapping functionality with ddoc/dpl-docs, and that is relatively unknown within the community sounds like a tall order.Sass doesn't overlap with ddoc. -- /Jacob Carlborg
Apr 21 2014
On 4/21/14, 11:51 PM, Jacob Carlborg wrote:On 21/04/14 23:23, Andrei Alexandrescu wrote:Good to know, thanks.I confess getting a bit uncomfortable about adding new dependencies at this point. We depend on dpl-docs already, and the tool was difficult to install and broke from one dmd release to the next. Sönke was nice and proactive about it, but he's an active member of the community. If we find issues with tooling coming from the outside - and we will - we're on our own. It would help if many people in the community are fluent with them.I've used Sass a lot. Although not via node.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? AndreiAdding 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.
Apr 22 2014
On 2014-04-22 18:38, Andrei Alexandrescu wrote:I'm clearly outta my depth here, basing myself off of giving http://sass-lang.com/guide a couple minutes. From what I can tell here's how ddoc matches up sass features: Pre-processing: yes Variables: yes Nesting: no Partials, Import: somewhat (by passing several ddoc files to dmd) Mixins: yes Extend/Inheritance: no Operators: no I'm glad to see a revamp of dlang.org happening. Again if the added tools bring great advantages with them, fine. But we can't add dependencies carelessly and only for minor convenience.I'm not going to argue which is best. But since I started to use Sass, I see no reason to use plain CSS. Even just for nesting, which is the most used feature I've seen people use, I think it's worth it. Although, I'm using Ruby on Rails which comes bundled with Sass. -- /Jacob Carlborg
Apr 22 2014
On Tuesday, 22 April 2014 at 19:34:08 UTC, Jacob Carlborg wrote:On 2014-04-22 18:38, Andrei Alexandrescu wrote: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).I'm clearly outta my depth here, basing myself off of giving http://sass-lang.com/guide a couple minutes. From what I can tell here's how ddoc matches up sass features: Pre-processing: yes Variables: yes Nesting: no Partials, Import: somewhat (by passing several ddoc files to dmd) Mixins: yes Extend/Inheritance: no Operators: no I'm glad to see a revamp of dlang.org happening. Again if the added tools bring great advantages with them, fine. But we can't add dependencies carelessly and only for minor convenience.I'm not going to argue which is best. But since I started to use Sass, I see no reason to use plain CSS. Even just for nesting, which is the most used feature I've seen people use, I think it's worth it. Although, I'm using Ruby on Rails which comes bundled with Sass.
Apr 22 2014
On Tuesday, 22 April 2014 at 16:38:04 UTC, Andrei Alexandrescu wrote:On 4/21/14, 11:51 PM, Jacob Carlborg wrote:It's not competing with Sass. Sass would make it easier for me to faster write needed styling and also more importantly to have style files easy to maintain later (I had worked few times with monolithic 3000+ lines long CSS files and can attest that it's much easier to work with nice hierarchy of small SCSS files). I can surely do without Sass and use plain CSS but to keep it maintainable I would need to split it to multiple files and would need a tool to concat those later to the target CSS (this can be done with cat but it's non-standard on windows) and then I would need a tool to minify that CSS. These are simple tools, and they can be written from scratch in D (which I would like to do, but then I won't be working on redesign while those are done). If I would use Sass, I would not only get really nice and powerful DSL to write styles in but I would get tools to concat and minify CSS. As I've said in message to Dicebot I would not use npm as it would be bad marketing, but I would really like to use libsass (sassc - the compiler, to be precise, libsass is a library used by sassc) which written in C. If that's too much dependencies I'll have to go with plain CSS files. And I've already decided to use Make instead of gulp (a npm packaged build tool for node.js). The only thing that remains is JavaScript minifyer. I have tried almost all of them, Google Closure Compiler, YUICompressor, jsmin, UglifyJS and in my experience UgifyJS[1] is definitely the best tool for that task (closure compiler can get your slimmer files but you must stick to Google's rules of writing and annotating your code, which I find too limiting). The only problem with UglifyJS is that it's a Node.js library/tool... So I don't know what to do about that. Sure, there are online versions of both Closure Compiler and UglifyJS but they cannot be integrated in build system (well, not without requirement of internet connection). I wonder if DMDScript's parser could be used to write JS minifier in D. This is actually something I would really like to look into but there is definitely not small amount of work needed to develop a tool like that. So it will have to wait, sadly. So, as I'm not aware of any native good JS minifing tool I'd skip that step for now. We can optimize that later (anyway, I'll keep JS usage on bare minimum). The only question yet remaining is if I can depend on sassc[2] or not? [1] https://github.com/mishoo/UglifyJS [2] https://github.com/hcatlin/sasscOn 21/04/14 23:23, Andrei Alexandrescu wrote:Good to know, thanks.I confess getting a bit uncomfortable about adding new dependencies at this point. We depend on dpl-docs already, and the tool was difficult to install and broke from one dmd release to the next. Sönke was nice and proactive about it, but he's an active member of the community. If we find issues with tooling coming from the outside - and we will - we're on our own. It would help if many people in the community are fluent with them.I've used Sass a lot. Although not via node.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? AndreiAdding 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.
Apr 22 2014
I wrote a css expander that has a little bit of SASS features. Previously it was hidden in my html.d on my misc. github, but I just now made it a standalone program in a separate repo: https://github.com/adamdruppe/cssexpand Check out the demo input file https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css and demo result file https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css to get an idea of what it does.
Apr 22 2014
On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:I wrote a css expander that has a little bit of SASS features. Previously it was hidden in my html.d on my misc. github, but I just now made it a standalone program in a separate repo: https://github.com/adamdruppe/cssexpand Check out the demo input file https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css and demo result file https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css to get an idea of what it does.Wow, this looks really nice! It has variables, mixins, nested selectors and includes.. That's all I need! Only.. any chance of making ¤ prefix configurable via cmdline params? :) Ideally I would use as prefix, but that may interfere with CSS -rules (I see you have CssAtRule class to handle those), so I'd use some character that's easier to type like $ (but that is used for parent selector in upcoming CSS 4)...
Apr 22 2014
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
On 4/23/2014 9:11 AM, Adam D. Ruppe wrote:On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic wrote:"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.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!
Apr 23 2014
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
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
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:Thanks! I will be looking forward to it on the dub repository.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.Okay, doesn't look too bad of a deal that.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
On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:I wrote a css expander that has a little bit of SASS features. Previously it was hidden in my html.d on my misc. github, but I just now made it a standalone program in a separate repo: https://github.com/adamdruppe/cssexpand Check out the demo input file https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css and demo result file https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css to get an idea of what it does.This is awesome. I think I might try it out for my next web-dev contract. If it could be put on code.dlang.org that would be awesome. I've always been tempted to use Sass or similar, but this seems like the simple tool I've actually wanted.
Apr 23 2014
On 4/23/2014 5:55 PM, John Colvin wrote:On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe 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.I wrote a css expander that has a little bit of SASS features. Previously it was hidden in my html.d on my misc. github, but I just now made it a standalone program in a separate repo: https://github.com/adamdruppe/cssexpand Check out the demo input file https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css and demo result file https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css to get an idea of what it does.This is awesome. I think I might try it out for my next web-dev contract. If it could be put on code.dlang.org that would be awesome. I've always been tempted to use Sass or similar, but this seems like the simple tool I've actually wanted.
Apr 23 2014
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
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
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
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:Can we have it as a library? Instead of as only an executable? Aka no main function.If it could be put on code.dlang.org that would be awesome.http://code.dlang.org/packages/cssexpand
Apr 23 2014
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
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: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.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.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
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
Am 24.04.2014 16:42, schrieb Adam D. Ruppe:On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole wrote: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.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?
Apr 24 2014
Am 24.04.2014 17:59, schrieb Sönke Ludwig:Am 24.04.2014 16:42, schrieb Adam D. Ruppe: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.On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole wrote:This should automatically yield two configurations - "application" and "library": ...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?
Apr 24 2014
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: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.If it could be put on code.dlang.org that would be awesome.http://code.dlang.org/packages/cssexpand
Apr 24 2014
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
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
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
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
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:I think it is very important to dogfood here and add any currently missing dependencies as dub packages instead.On 4/19/14, 1:02 AM, 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..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 21 2014
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
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
On 2014-04-22 09:56, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>" wrote:I never use css macros-tools, regular template libraries are usually better (e.g. jinja2 allows me to execute python expressions if needed). With current browsers the CSS is getting much more streamlined too and the worst browser bugs require javascript detection anyway so macros don't cut it.I usually use these languages together with Ruby on Rails. With the assets pipeline in RoR it's possible to pipe several pre-processors together. Erb (Embedded Ruby) -> Sass -> CSS. -- /Jacob Carlborg
Apr 22 2014
On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:On 21/04/14 23:33, Dicebot wrote: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 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.
Apr 22 2014
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: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..On 21/04/14 23:33, Dicebot wrote: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 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.
Apr 22 2014
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: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.On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote: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..On 21/04/14 23:33, Dicebot wrote: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 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.
Apr 23 2014
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
On 4/22/2014 6:26 PM, Martin Nowak wrote:On 04/21/2014 05:48 PM, Aleksandar Ruzicic 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.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
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
On 4/23/2014 2:34 AM, Jacob Carlborg wrote:On 23/04/14 00:57, Nick Sabalausky wrote:They don't work. But...maybe they're only intended to be single-page-only examples? (Now that I think about it...) 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 ;)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?
Apr 23 2014
On Wed, Apr 23, 2014 at 06:08:52PM -0400, Nick Sabalausky via Digitalmars-d wrote: [...]But I have noticed a lot of the sites that use anchor links to switch to completely different pages are basically broken. Since the very *beginning* of HTML, links have always been downright trivial to implement, and have always been considerably *easier* to *not* require JS. It's pretty much the single simplest, easiest, most fundamental thing in HTML. And yet, more than a decade now after <a onclick="..."> linking inexplicably appeared, some people are *still* trying to implement links using JS. It's insane.[...] I'm still amazed at the number of news sites that have non-functional links the moment you disable JS. I had been running my browser with JS turned on by default for many years, until sometime in the last few years I got so sick of JS eating up CPU, memory, causing needless browser slowdowns, popping up unwanted ads and nag dialogs, that now I'm back to JS being off by default, and only (grudgingly) enabled for a handful of specific sites that actually *need* it. It's amazing how much faster the web suddenly became, overnight. And it's equally amazing how many links stop working without JS. It boggles the mind... doesn't HTML have a built-in link tag for that very purpose?! Another new fad nowadays seems to be CSS popups that need JS to make them go away. My usual reaction to that is to close the tab and move on. Or, if I'm feeling particularly tolerant that day, switch to user stylesheet mode (i.e., completely disregard the site's CSS and use my own), and just scour the raw text for the real content (which usually occupies, oh, 20% of the total text on the page -- apparently nowadays minimizing your S/N ratio is in, providing useful content is out). Doesn't fix the JS link issue, though, but so far, I've decided that it's not worth the bother to find out what's behind such non-working links -- esp. since Google will readily give me pages upon pages of other places where I can get similar information! >:-)However, you'll have to pardon that little rant. When I posted that "Apparently they can't even manage make basic links work properly", I swear it wasn't my intention to do another JS-rant. Coming from me, JS rants are pretty much redundant at this point ;)JS rants are fun. ;-) T -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true. -- Robert Wilensk
Apr 23 2014
(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-developersAnother 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 contentI love this FF extension: https://adblockplus.org/en/elemhidehelper If I can't get rid of the garbage with that, the site's not worth spending another second on. I won't be bothered to even *think* about some poorly-made site's CSS, let alone touch any custom stylesheets.(which usually occupies, oh, 20% of the total text on the page -- apparently nowadays minimizing your S/N ratio is in, providing useful content is out).Yup. Makes me miss "markup". But then I go back to my own site, type <b></b> instead of <span class="something-that-implicitly-says-font-weight-bold-in-the-css"></span>, and all is well. Bonus points for me whenever <b> offends anyone's sense of "proper" HTML. :) As if <b> hasn't always implied the semantics of "emphasis" anyway...not that anyone's ever had any real use for semantic "which text is emphasized?" for any purpose besides "Should this text be rendered in bold/italic or not?" Funny though...I've never heard any of the semantic-web-loving, <b>/etc haters complain about things like Markdown ;)esp. since Google will readily give me pages upon pages of other places where I can get similar information! >:-)Yea that's a big thing, too. So many designers actually believing their site is so special that people won't just move on or that being hitech-elitist won't hurt their site.JS rants are fun. ;-)Heh, yea, it's an addiction :)
Apr 24 2014
On 24/04/14 00:08, Nick Sabalausky wrote:They don't work. But...maybe they're only intended to be single-page-only examples? (Now that I think about it...)Yes. Bootstrap won't touch your links with JavaScript, unless you tell it to.If so, then I must have misunderstood the examples. The fact that they're all pointing to different anchor links threw me off and made me assume they were supposed to be functional. (I'm accustomed to blank zero-length anchors being used to indicate "intentionally non-functional placeholder link".)Yeah, I don't know why they do that.But I have noticed a lot of the sites that use anchor links to switch to completely different pages are basically broken. Since the very *beginning* of HTML, links have always been downright trivial to implement, and have always been considerably *easier* to *not* require JS. It's pretty much the single simplest, easiest, most fundamental thing in HTML. And yet, more than a decade now after <a onclick="..."> linking inexplicably appeared, some people are *still* trying to implement links using JS. It's insane.I hate that as well. Sometimes I come to a page, with JS disabled, and it's completely blank. Then my thought process goes something like this: "Hmm, is it loaded. Yes, strange. Oh right I've disabled JavaScript. What is this pieces of crap, can't they design a web site without JS".However, you'll have to pardon that little rant. When I posted that "Apparently they can't even manage make basic links work properly", I swear it wasn't my intention to do another JS-rant. Coming from me, JS rants are pretty much redundant at this point ;)No worries :) -- /Jacob Carlborg
Apr 23 2014
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
On Tuesday, 22 April 2014 at 22:26:39 UTC, Martin Nowak wrote:On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:I would use Foundation[1] instead of Bootstrap. [1] http://foundation.zurb.com/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
On 4/22/2014 7:29 PM, Aleksandar Ruzicic wrote:On Tuesday, 22 April 2014 at 22:26:39 UTC, 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*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
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
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
On 4/23/2014 2:47 AM, Martin Nowak wrote:I didn't say style was irrelevent. I only said that there should actually *be* content.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 23 2014
Sorry for the irony :), indeed fluffy sites without content are useless. Reminds me of http://vimeo.com/89527215.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
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
On Wednesday, 23 April 2014 at 07:02:50 UTC, Martin Nowak wrote: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.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
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
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote:So, what do you guys think? -- AleksandarI do agree that the design of the current site is rather dated. I rather like your new proposed design as well. One thing that could be nicer is the search bar being a button to click. It's standard now to just make it an input of type search with place-holder text now, which is faster and more useable. Even better, it could be automatically focused on when you load the (documentation) page so you can immediately start typing to look up an API / language feature. People who go directly to the homepage are likely coming to check out what D is or why they should use it (which the homepage shows), find a download button (which could still be improved upon), or search the documentation (which is still a few clicks away). I'd argue that most people are going for the third option since you don't need to download often and people just checking it out don't return frequently to check it out again. Having an immediate search field, ideally with autofocus, makes finding documentation a very easy task. A prominent download button immediately visible on the home page rather than the top nav-bar would be an improvement as well. Practically every site with something to download does this, for good reason. It's one of the first things that should jump out at you when you view the site, making it as little effort as possible to commit to at least downloading the installer (see Dart, Python, Rust, Go, Ruby, etc). The longer / more effort it takes to do something, the less likely people are to try it unless they're already very convinced it's something they need.
Apr 18 2014
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: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!).So, what do you guys think? -- AleksandarI do agree that the design of the current site is rather dated. I rather like your new proposed design as well. One thing that could be nicer is the search bar being a button to click. It's standard now to just make it an input of type search with place-holder text now, which is faster and more useable. Even better, it could be automatically focused on when you load the (documentation) page so you can immediately start typing to look up an API / language feature.People who go directly to the homepage are likely coming to check out what D is or why they should use it (which the homepage shows), find a download button (which could still be improved upon), or search the documentation (which is still a few clicks away). I'd argue that most people are going for the third option since you don't need to download often and people just checking it out don't return frequently to check it out again. Having an immediate search field, ideally with autofocus, makes finding documentation a very easy task.I'm slightly against autofocus on search field, as I am one of people who use Backspace to navigate to previous page and I'm always frustrated when I hit Backspace on Google search results page and it's not taking me to previous page. But if majority thinks that autofocus on search is a good thing (I also think that not many people use Backspace as a means of navigation) than I would make it like that (and if there would be that little preferences page/popup this option is something that can go there together with justification settings).A prominent download button immediately visible on the home page rather than the top nav-bar would be an improvement as well. Practically every site with something to download does this, for good reason. It's one of the first things that should jump out at you when you view the site, making it as little effort as possible to commit to at least downloading the installer (see Dart, Python, Rust, Go, Ruby, etc). The longer / more effort it takes to do something, the less likely people are to try it unless they're already very convinced it's something they need.Download sites do that, so does sites that sell software. I think that dlang.org should focus on promoting D as a language, and compiler implementations should not be in spotlight. Also I think that having Download in top-nav as a first option is prominent enough. I've put what I think are the most important sections in top-nav bar (other navigation items should go to context-sensitive sidebar).
Apr 19 2014
On Saturday, 19 April 2014 at 08:16:20 UTC, Aleksandar Ruzicic wrote: ...Download sites do that, so does sites that sell software. I think that dlang.org should focus on promoting D as a language, and compiler implementations should not be in spotlight. Also I think that having Download in top-nav as a first option is prominent enough. I've put what I think are the most important sections in top-nav bar (other navigation items should go to context-sensitive sidebar).Also can we have things like a getting started guide? That really impeded me at least when I was starting out.
Apr 19 2014
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
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
On Monday, 21 April 2014 at 11:42:54 UTC, Kagamin wrote:Autofocus breaks site navigation: instead of returning to where you were previously, you end up focused on search box, which is really annoying. It also breaks page navigation (similar mistake: floating top panel on dart site). Whether it's standard or not, I don't know, because when I see such disgusting UX, I leave the site and never return if possible.I hate that too. It also breaks in-page search with "/", which I use a lot. In fact, I get seriously annoyed whenever a web site does *anything* to make my browser behave in an unexpected, non-standard way. Like those sites that hijack the arrow keys for navigation between images or blog posts. Or GitHub's keyboard shortcuts. Grrrr... When I want that stuff, I use a browser plug-in like Vimperator or Vimium. I shouldn't have to install an add-on to *disable* it.
Apr 21 2014
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: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).Autofocus breaks site navigation: instead of returning to where you were previously, you end up focused on search box, which is really annoying. It also breaks page navigation (similar mistake: floating top panel on dart site). Whether it's standard or not, I don't know, because when I see such disgusting UX, I leave the site and never return if possible.I hate that too. It also breaks in-page search with "/", which I use a lot. In fact, I get seriously annoyed whenever a web site does *anything* to make my browser behave in an unexpected, non-standard way. Like those sites that hijack the arrow keys for navigation between images or blog posts. Or GitHub's keyboard shortcuts. Grrrr... When I want that stuff, I use a browser plug-in like Vimperator or Vimium. I shouldn't have to install an add-on to *disable* it.
Apr 21 2014
Different strokes for different folks. https://github.com/rejectedsoftware/ddox/pull/49
Apr 25 2014
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
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
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
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
On Tuesday, 22 April 2014 at 22:24:25 UTC, Martin Nowak wrote: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.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
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:[...][...] 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: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.On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote: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. :PI 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).TBH, I find this "pixel perfect" obsession to be really silly. It shows that web developers don't understand that what the user sees is NOT what developers see, because browsers come in many sizes and shapes, and users' screens also come in many sizes and shapes. "This site is best viewable in AAAxYYY resolution" is so last century. When are we gonna grow out of that?! On Thu, Apr 24, 2014 at 01:57:32PM +0000, Adam D. Ruppe via Digitalmars-d wrote:Another thing that kills me about the new "big picture up top, scroll to gigantic say-nothing text below" fad.... The text below sounds like there might be some more learning to do. So I try to click on the headers.... nothing happens. No see more link. Apparently "Feature rich: we have more features than anybody!" is all they have to say. No explanation of what those features are. <a href="this-makes-me-angry-because-it-sux">Hatred.</a>Yeah I noticed that about recent new sites. But then again, it's more tolerable than the old "jampack every possible marketing slogan you can onto a presumed 640x480 browser window until it's unreadably cluttered" approach, which *still* conveyed basically no information. "Feature-rich" has become one of those meaningless buzzwords that really should be added to this page: http://www.dack.com/web/bullshit.html :-P Along with "innovative", "comprehensive", "powerful", "creative", "cloud", "mature", etc., all of which have lost their meaning from marketing overuse. T -- The diminished 7th chord is the most flexible and fear-instilling chord. Use it often, use it unsparingly, to subdue your listeners into submission!
Apr 24 2014
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: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. :-)On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:[...][...] 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: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.On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:Funny. I find anything below 16pt unreadably small.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).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 seeIf 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
Am 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>":According to the CCS 2.1 standard 1 px == 0.75pt. http://www.w3.org/TR/CSS21/syndata.html#length-units Thus: 16pt => 12px => 3.1mm at a reading distance of 71 cm.16pt => 21.3px
Apr 24 2014
On Thursday, 24 April 2014 at 15:55:36 UTC, Sönke Ludwig wrote:Am 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>":Yeah, I thought it was a bit odd, it sounded more like 9pt. I guess Theo should look into the DPI settings if possible.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
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: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 HangsAm 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang gmail.com>":Yeah, I thought it was a bit odd, it sounded more like 9pt. I guess Theo should look into the DPI settings if possible.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
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? -- AleksandarAny updates? Any help needed pushing this forward?
May 29 2014
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
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
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
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
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
On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:Whoops. http://imgur.com/oSHfFek,Mc81UYMThe 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
On Saturday, 31 May 2014 at 20:38:41 UTC, Meta wrote:On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:Yes, a darker background does look quite nice.On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:Whoops. http://imgur.com/oSHfFek,Mc81UYMThe 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
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: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_winderOn Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:Yes, a darker background does look quite nice.On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:Whoops. http://imgur.com/oSHfFek,Mc81UYMThe 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
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
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: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.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.
Jun 02 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.orgI 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
On Saturday, 31 May 2014 at 20:52:56 UTC, Kapps wrote:One thing that's a bit broken is that "Modern convenience. Modelling power. Native efficiency." wraps to put "efficiency." on a different line. Perhaps the text should be made smaller there. Another thing that I'd like to see is a much more prominent download button. It's definitely easier to find with this redesign, but a prominent download button is one of the most important things when you're trying to get someone to try something, right after a useful code sample (ideally with the mentioned REPL).Yes, that line should be smaller. Maybe the download link at the top could be another colour. Maybe next to the REPL it can say, "Download now!"
May 31 2014
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
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
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
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.+1Now 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
On Sunday, 1 June 2014 at 03:26:30 UTC, Rikki Cattermole wrote:The problem with diet is it compiles directly to D code, hence forth its not really possible at the moment. However as I believe Sonke has said previous it is out of scope of Vibe. Its actually in the scope of Cmsed instead. I have looked into doing just this, reloading of templates. And from what I can ascertain reliably we need shared library support. While this is doable upon Linux, it isn't on Windows. Until its available on Windows I will not use it. My thread on the dub forum is here[0]. Basically I am also blocked by dub, to be able to grab all the previous templates ext. From libraries and push them into a findable place at runtime.I would also consider using a different template engine entirely, one which is less powerful but which can be automatically recompiled at runtime. I would consider something with diet syntax, but where only some of the D language parts actually work. (The '-' syntax parts.)I personally allow for atleast 1.5 to 2gb of ram to build anything with D. Cmsed base package alone takes around 700mb. And thats with a LOT of CTFE work going on. I can only see that increasing. So I'd like a way for dmd to utilize memory better even if it means slowing down for larger builds. For small builds the current way is great, just for larger we need alternative means.I was thinking about this, and it might be good to offer a switch for lower memory build profiles. As far as I recall, I believe the memory usage comes from the philosophy that you can malloc, malloc, malloc, then exit the process for speed. I think it was freeing some memory and so on which would reduce build speed. I might be talking nonsense, but it would be nice to have an option to reduce build speed and also reduce memory usage. Of course, having the best of both worlds is always great.
Jun 01 2014
Am 01.06.2014 11:54, schrieb w0rp:On Sunday, 1 June 2014 at 03:26:30 UTC, Rikki Cattermole wrote: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.dThe 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.)
Jun 01 2014
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
On Sunday, 1 June 2014 at 05:46:57 UTC, Russel Winder via Digitalmars-d wrote: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 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.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
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
I just updated the site. Here are the main changes. * The background is now dark. I tried a linear-gradient for a little bit, but it made scrolling down the page much, much slower. I shall try out drawing a gradient in GIMP instead. * The column on the right gets fixed when you scroll down, but the Bootstrap tool for this has a bug when you scroll all the way to the bottom some times which I need to get fixed. * I added a download page I wrote a bit of text for. Check out the download page here. http://w0rp.com:8010/download The old URL (download.html) is set up with a redirect. (Redirecting like this is vital for SEO.) I want to fix that scrolling bug, account for resizing a window smaller than the length of the right column (I've seen this issue come up time and time again in browsers), Give the download button on the top a bit more colour, and get a nice gradient in which doesn't slow the page down. It was looking pretty good, but I absolutely will not use linear-gradient on the page after I saw how it ruined smooth scrolling. Also, the table of contents there is currently a manual job, but I reckon there are clever things I can do with diet to generate it. Something like this... - import dlang.toc; append content ... - heading(h2, "Title"); ... append extra-sidebar - toc(); I bet I can make this syntax possible. Out for now.
Jun 01 2014
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
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: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.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
https://github.com/w0rp/new-dlang.org/blob/master/src/dlang/toc.d I just implemented my Table of Contents idea for use in the diet templates. // Write a heading and add it to the table of contents in one go. |!= h2(toc, "anchor", "Title") // Write the table of contents out as html. |!= toc.write("Title") There are functions named 'h1' to 'h6' to use, and it works. Now it should be dead simple to write headings and generate a table of contents for a number of pages.
Jun 01 2014
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
On Sunday, 1 June 2014 at 13:29:38 UTC, w0rp wrote:I just updated the site. Here are the main changes. * The background is now dark. I tried a linear-gradient for a little bit, but it made scrolling down the page much, much slower. I shall try out drawing a gradient in GIMP instead. * The column on the right gets fixed when you scroll down, but the Bootstrap tool for this has a bug when you scroll all the way to the bottom some times which I need to get fixed. * I added a download page I wrote a bit of text for. Check out the download page here. http://w0rp.com:8010/downloadI 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
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
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
Shouldn't it be measured in characters instead of percentage of page width?
Jun 03 2014
I have updated the site and the repository with all of the D changelogs split into their own pages. I had to reformat a few things, primarily example code, so it would fit nicely in smaller column sizes. I marked sections with headings so it fits into a table of contents. One major thing that's missing is syntax highlighting, as I'm not sure what to use for that. http://w0rp.com:8010/changelog Here is what I've noticed so far that's good about the diet templates. 1. The template syntax, taken from Jade, is easy to understand and clean. 2. I can do tricks like the table of contents easily. However, with the good comes the bad. 1. If you are recompiling one template, you are recompiling *all* of them. I'm getting closer to 100 templates, and it takes seconds to compile. 2. Compiling many templates allocates like crazy during compile time and eats memory like a hog. It takes *5GB* of RAM to compile all of these templates. It seems like the vibe.d diet templates take heap allocation during compilation time way, way too far, to the point of them being impractical to use for large websites. Somewhere around 100 templates is something I would expect for a reasonably sized website. So I have a plea or two for vibe.d In addition to recompiling diet templates automatically during development, which has been mentioned before, I believe there should be an option to defer compilation of a template the first time, during development, until you view a page using it for the first time. This woud solve the slower compilation issue, because then you'd only pay for what you used. Second, something must be done about memory allocation during compilation of diet templates. There's too much going on there. That's it for now.
Jun 09 2014
Am 10.06.2014 02:18, schrieb w0rp:I have updated the site and the repository with all of the D changelogs split into their own pages. I had to reformat a few things, primarily example code, so it would fit nicely in smaller column sizes. I marked sections with headings so it fits into a table of contents. One major thing that's missing is syntax highlighting, as I'm not sure what to use for that. http://w0rp.com:8010/changelog Here is what I've noticed so far that's good about the diet templates. 1. The template syntax, taken from Jade, is easy to understand and clean. 2. I can do tricks like the table of contents easily. However, with the good comes the bad. 1. If you are recompiling one template, you are recompiling *all* of them. I'm getting closer to 100 templates, and it takes seconds to compile.Sounds kind of like an ironic joke when viewed from a C++ background ;) But yes, it's definitely not what you want to have for D. I'm not sure how much can be done about that, though - except from rewriting the CTFE engine with performance in mind (maybe even using a JIT compiler). Or maybe it's possible to be more liberal with algorithmic optimizations when the CTFE memory usage brought to a reasonable level.2. Compiling many templates allocates like crazy during compile time and eats memory like a hog. It takes *5GB* of RAM to compile all of these templates.Yes, which is why (at least with the current compiler front end) I'd strongly recommend to put long text content in a different format that is inserted at runtime (e.g. DDOC or Markdown).It seems like the vibe.d diet templates take heap allocation during compilation time way, way too far, to the point of them being impractical to use for large websites. Somewhere around 100 templates is something I would expect for a reasonably sized website.It's not heap allocations. The problem is that during CTFE, currently basically every variable change allocates memory that is never freed again. I've used a few tricks to get the memory usage down (which is why the Diet compiler source code doesn't look very pretty), but basically the only way to get reasonable memory use is to fix the D front end.So I have a plea or two for vibe.d In addition to recompiling diet templates automatically during development, which has been mentioned before, I believe there should be an option to defer compilation of a template the first time, during development, until you view a page using it for the first time. This woud solve the slower compilation issue, because then you'd only pay for what you used.That would probably even be a side-effect of the implementation of separately compiled templates (eagerly compiling them will require some additional code).Second, something must be done about memory allocation during compilation of diet templates. There's too much going on there. That's it for now.See also https://issues.dlang.org/show_bug.cgi?id=6498
Jun 10 2014
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
Am 10.06.2014 12:25, schrieb w0rp:On Tuesday, 10 June 2014 at 08:12:53 UTC, Sönke Ludwig wrote: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.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
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
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: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.* 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
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
On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:Am 10.06.2014 12:25, schrieb w0rp: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.On Tuesday, 10 June 2014 at 08:12:53 UTC, Sönke Ludwig wrote: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.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
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:[…]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?* 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.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
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
On Tuesday, 10 June 2014 at 14:50:51 UTC, Sönke Ludwig wrote:Am 10.06.2014 14:31, schrieb Kiith-Sa:I can definitely live without Markdown style tables. I'm happy enough to write HTML for that.(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
I thought I'd post an update on this work so I don't leave any people hanging who are wondering about this. I haven't had the time in the last week or so to work on this as I have been very busy recently with other responsibilities. With my day job in particular, I will be in Berlin most of next week hosting a conference with my company. Because it's a small world, by pure coincidence Sociomantic are actually sponsoring this conference. (I doubt the marketing guys talk to the D programmers that much, though.) http://www.performancemarketinginsights.com/14/europe/sponsor/sociomantic/ However, after I get back I will defintely work on this redesign some more. Unless somebody pins me down, I'll keep going with it. I only just realised that I made the terrible mistake of not pushing my most recent changes, so you can find them now on GitHub. I started working on discovering Markdown files at runtime for filling in a sections of pages, like center part of changelog pages, and generating the table of contents from the HTML automatically. Because the prospect of parsing HTML myself scares me, I just copied in Adam D Ruppe's DOM library for that. I hope that I have properly attributed the authors for that code, please advise me if I should add any additional attribution in there otherwise. The early result of that I think has been pretty good. I can edit a file and see a change pretty quickly. I lost the functions I was using to generating the Bugzilla links, but I'm going to replacing them with links to /bug/<id> instead, and making that page redirect to the right place, just so I can make my Markdown files a little smaller. The amount of memory consumed while compiling is better, going from something like 2GB to 1.2GB, because there aren't tons of Diet templates to build in anymore. The Markdown parsing is just the library functionality that comes with vibe.d. I totally have not converted all of the pages from Diet to Markdown yet. In fact, if you run the site as is now, you can't see any of the changelog pages except 2.000 anymore. Plus, you could perhaps do something involving caching files instead of loading them from the drive all the time, but I just want something that works for now. So there's my update for now.
Jun 20 2014
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: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).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 Monday, 30 June 2014 at 21:11:31 UTC, Gary Willoughby wrote:On Sunday, 29 June 2014 at 22:15:48 UTC, 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 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 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
On 01/07/2014 8:40 AM, Alix Pexton wrote:On 01/07/2014 7:42 AM, w0rp wrote: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...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
On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:On 01/07/2014 7:42 AM, w0rp wrote: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.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
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:I'll fix that in the interim by converting the font into a shape instead.On 01/07/2014 7:42 AM, w0rp wrote: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.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
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: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 IainOn Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:I'll fix that in the interim by converting the font into a shape instead.On 01/07/2014 7:42 AM, w0rp wrote: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.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
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 IainI 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
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: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/676On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp 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 IainOn Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:I'll fix that in the interim by converting the font into a shape instead.On 01/07/2014 7:42 AM, w0rp wrote: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.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
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: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 IainOn 1 July 2014 13:40, w0rp via Digitalmars-d <digitalmars-d puremagic.com> wrote: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.On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp 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 IainOn Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:I'll fix that in the interim by converting the font into a shape instead.On 01/07/2014 7:42 AM, w0rp wrote: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.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
On Tuesday, 1 July 2014 at 12:40:21 UTC, w0rp wrote:On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:I did that a couple years ago: http://goo.gl/trMh6kOn Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:I'll fix that in the interim by converting the font into a shape instead.On 01/07/2014 7:42 AM, w0rp wrote: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.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
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
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: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.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
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: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.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
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
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
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:It is not about liking it or not...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 02 2014
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
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
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
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 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 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
On 03/07/2014 12:35 PM, w0rp wrote:On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote: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...On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote: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 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
On Thursday, 3 July 2014 at 11:35:36 UTC, w0rp wrote:On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote: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)On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote: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 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
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
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
Am 10.06.2014 16:06, schrieb Andrei Alexandrescu:On 6/10/14, 3:42 AM, Sönke Ludwig wrote: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.* 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
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:en* Are there any other opinions on this? I remember that there have be=fsome strong proponents of using DDOC for things, so it would be bad i==in the end Markdown were to be dropped, after all of the work has already been done. Personally I'd strongly favor Markdown, though.I think ddoc is a lot more flexible than markdown, and I'm baffled by =the claim that ddoc is difficult to learn. That said I do agree it's a==turnoff for first-time website contributors. IMHO if we switch away fr=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
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
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
On Tuesday, 10 June 2014 at 11:09:41 UTC, Jacob Carlborg wrote:On 10/06/14 10:12, Sönke Ludwig wrote: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.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?
Jun 10 2014
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:We can't because Diet templates may contain arbitrary D code inline.On 10/06/14 10:12, Sönke Ludwig wrote: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.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?
Jun 10 2014
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
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.)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.)...Try that with livereload as well. For CSS it doesn't need to reload the whole page, it just inserts the new CSS.
Jun 02 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/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
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
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? -- AleksandarLooks 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
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
On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:[I haven't had time to follow the entire thread, but] I like the design, it's a good starting point. Especially the integration of the logo. Nice and clean. (The current logo is just too bulky and clumsy, imo*) However, my experience tells me that we should wait with redesigning it until the technical issues/problems have been solved, e.g. the migration to vibe.d, which I'm in favor of (I've had good experiences with vibe.d so far), and the doc generation issue etc etc. Once that is out of the way, we can think about new designs.I've been focusing on getting a working site with vibe.d. Integrating the ddox document generator is a high priority for me right now, especially since I've finished a lot of work for formatting the changelog pages.Yours is very nice and "modern". However, we also have to take mobile devices (tablets, smartphones) into account and see how we can adapt to these (different layouts or one for all?).I used the Bootstrap framework, which I have also used in my day job. Bootstrap makes producing a responsive design pretty easy. I've been periodically testing pages on smaller screens. Firefox's 'reponsive design mode' helps a lot with this.Another issue is that we don't have to jump on any bandwagon (every time the "fashion" changes), we can roll our own design, one that fits the community's and the language's needs, regardless of what is trendy or "modern" at any given time (don't imitate, innovate!).There are many different designs you could produce. Many design choices are subjective, though not all of them. I think my goals for the work I've been doing are as follows. * Improve site navigation. * Improve display across different devices. * Improve the quality of text to make it easier to read. * Make it easier for newcomers to edit, to encourage contribution. * Run it all with D to tick a "official D site made in D" checkbox. There are others, but those are the important ones.
Jul 03 2014
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
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: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.* 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 couldMight be a bit over the top for dlang.org though ^^ A...Powered by Martian Technology
Jul 03 2014
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote: […]Powered by Martian TechnologySarcasticRover 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: […]He also get angry when you mention that using the imperial system is idiotic.Powered by Martian TechnologySarcasticRover is telling us "Do not come to Mars." Perhaps its commentary need censoring ;-)
Jul 08 2014
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:But the imperial system *isn't* idiotic. :o) And everyone should drive on the left.On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote: […]He also get angry when you mention that using the imperial system is idiotic.Powered by Martian TechnologySarcasticRover is telling us "Do not come to Mars." Perhaps its commentary need censoring ;-)
Jul 08 2014
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
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: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).On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via Digitalmars-d wrote:But the imperial system *isn't* idiotic. :o) And everyone should drive on the left.On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote: […]He also get angry when you mention that using the imperial system is idiotic.Powered by Martian TechnologySarcasticRover is telling us "Do not come to Mars." Perhaps its commentary need censoring ;-)
Jul 09 2014
On 09/07/2014 12:36 PM, Chris wrote:On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via Digitalmars-dDriving 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...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
On Wednesday, 9 July 2014 at 15:34:03 UTC, Alix Pexton wrote:On 09/07/2014 12:36 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.On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via Digitalmars-dDriving 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...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
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
On Wednesday, 9 July 2014 at 21:20:28 UTC, Alix Pexton wrote:On 09/07/2014 4:43 PM, Chris wrote: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.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...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
http://w0rp.com:8010/library/index.html I just updated the site hosted there with the work I've done on integrating the library documentation to date. I spent a lot of time staring at the pages for a while trying to figure out how to fit everything on a page decent. I admit to hacking the std.algoritm tables into not being tables, etc. I would very much appreciate any pull requests which improve on what I've done so far with it. It's all on GitHub in the usual place. https://github.com/w0rp/new-dlang.org Right now I'm using some of the layouts modified from Sönke's ddox templates, some modified from the dlang.org stuff. I'm using Adam D. Ruppe's DOM library, etc. I would like to properly attribute everyone for everything, so I would really appreciate input on where to credit people if I missed anything out. I have a COPYRIGHT file I can add people to if needed for that purpose, and I have retained the copyright comments in the arsd library. I still haven't included syntax highlighting. This really isn't hard, I just haven't gotten around to doing it yet. There's still a lot of work to be done, but it's one step closer now.
Jul 26 2014
..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
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
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
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:The std.algortihm documentation doesn't look good, and I don't have any good ideas for it.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.
Jul 26 2014
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
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:"No, I'm not in denial! It can't be!!!" :-P -- Живёшь только однажды.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
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:Well correction: I think it's among the better documented modules in std. -- AndreiOn 7/26/14, 6:30 PM, w0rp wrote:"No, I'm not in denial! It can't be!!!"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
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: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.On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:Well correction: I think it's among the better documented modules in std. -- AndreiOn 7/26/14, 6:30 PM, w0rp wrote:"No, I'm not in denial! It can't be!!!"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 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
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
Am 28.07.2014 09:18, schrieb Gary Willoughby:On Sunday, 27 July 2014 at 16:59:15 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. 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.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
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
On 7/28/14, 10:25 AM, Gary Willoughby wrote:On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:No, if you want professional results you have to do professional work. Andrei"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.
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: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:On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:No, if you want professional results you have to do professional work. Andrei"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.Also, and this needs to be stressed, the major part of w0rp's work so far is about the technical basis. You dismissed that as a minor detail, but it is not.The design is *the* most important part of the web site. Period! No one cares how it works, only the user experience of the site matters. Do you think users give a hoot how facebook works? Yes someone does have to do the 'technical stuff' behind the scenes. I do it on a daily basis but users don't care about the backend. Even if the case was made that *this* site is for engineers, the design will do. Well, systems engineers are must make this site as accessible for everyone. We need to 'sell' D, not make it look amateurish. In andreis Quo vadis talk i found it inspiring that he said in order to be considered a player we need to start acting like a player (paraphrasing). We need to start upping our game at this stuff! The whole reason for this site's existence is to 'sell' D as much as possible _including_ being used as a repository of knowledge. It will sell better if the design is good, easy on the eye and easy to find what you need. The w0rp design is none of those, stop pretending it is. Also who starts a project without designing it first? I mean honestly, why start such a major piece of work without even a vague spec? Has w0rp even asked users here what the site needs to encompass? Has the question been asked what content must exist, who needs what info and where, colour schemes, for mobile devices? etc. </flogging dead horse>
Jul 28 2014
Am 28.07.2014 21:13, schrieb Gary Willoughby:On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote: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, 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?Also who starts a project without designing it first? I mean honestly, why start such a major piece of work without even a vague spec? Has w0rp even asked users here what the site needs to encompass? Has the question been asked what content must exist, who needs what info and where, colour schemes, for mobile devices? etc. </flogging dead horse>He basically just took the mockup of Aleksandar Ruzicic, which was met with some optimism, and brought it to live. AFAICS that's all he really did WRT the design. The content was basically meant to stay the same as it is now*. * Honestly, apart from some important key parts, such as the front page or the download page, it would be insane to start over and redo the contents, just for the sheer amount of work that this would mean.
Jul 28 2014
On Monday, 28 July 2014 at 19:31:24 UTC, Sönke Ludwig wrote:Am 28.07.2014 21:13, schrieb Gary Willoughby: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.On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote: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, 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?Also who starts a project without designing it first? I mean honestly, why start such a major piece of work without even a vague spec? Has w0rp even asked users here what the site needs to encompass? Has the question been asked what content must exist, who needs what info and where, colour schemes, for mobile devices? etc. </flogging dead horse>He basically just took the mockup of Aleksandar Ruzicic, which was met with some optimism, and brought it to live. AFAICS that's all he really did WRT the design. The content was basically meant to stay the same as it is now*. * Honestly, apart from some important key parts, such as the front page or the download page, it would be insane to start over and redo the contents, just for the sheer amount of work that this would mean.
Jul 28 2014
On 7/28/14, 12:13 PM, Gary Willoughby wrote:On Monday, 28 July 2014 at 18:13:50 UTC, Andrei Alexandrescu wrote:Being honest does not entail being a jerk. -- Andrei (edited)On 7/28/14, 10:25 AM, Gary Willoughby wrote:Of course, but you have to be honest when things are not going well!On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:No, if you want professional results you have to do professional work. Andrei"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.
Jul 28 2014
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
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
Am 28.07.2014 19:25, schrieb Gary Willoughby:On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote: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."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.My perception was that he stated that his logo was just a placeholder and that someone would still have to get it right. The colors, as far as I can see, match the original logo pretty well, even though there are less highlights.See the first reply in this post in which i outlined my position: http://forum.dlang.org/thread/txdzebqxljlvjremintv forum.dlang.org and tell me again who is being destructive. In that same thread Walter is quoted as saying: "All excellent points, and I agree with you on all of them. And I like the current logo, and want to keep it." and yet w0rp still insists on going forward with this terrible design.There have been quite some different opinions on the logo topic, and personally I think that removing the "button" border is absolutely fine, while shape and color are important not to alter without very good reason. My understanding was that w0rp was basically intending to just flattening the logo, although I see that changing the shape has also been part of the discussion. My perception also was that Walter understood that the logo was to be completely changed instead of just flattened, but I may be completely wrong, of course. Anyway what's far worse is that the licensing situation of the current logo isn't clear and worst case it could mean that we'd have to switch the logo. But sorry, this is getting off topic.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.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 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.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
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: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.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
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
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: [...]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.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
Jul 27 2014
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
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
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 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.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.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.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 is not true. The largest screen width accommodates about 95 CPL for paragraphs.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.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.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
On Monday, 28 July 2014 at 08:30:05 UTC, w0rp wrote:Your comments are being ignored because your comments have been nothing short of a personal attack on myself. If you wish to make a serious contribution to a project, you should learn to use more tact, and speak to objective points of argument. A meaningful contribution would consist of contributing art assets, writing CSS, drafting mock-ups for improvements, etc. Thus far, you have failed to do any of this.I'm speaking the truth which often hurts. Your problem is you are not able to take any criticism whatsoever against this piece of work. The design is awful, period. I have nothing against you personally and i think it's good that you are initiating this effort but the design is the first thing that should be addressed and in no way be an afterthought. I apologise if i sound terse but usually in my line of work shoddy efforts have to be address upfront and with prejudice. The very first thing you should of done is to create mockups (in photoshop, etc) of what each page should look like and make sure the design can accommodate all the content. Once the design is approved then implement the site. The backend is inconsequential, use whatever you are comfortable with. Vibe.d, LAMP it doesn't matter. Users don't care about the backend. What matters is the user experience (especially within the documentation) and that is what should be addressed in a thoughtful professional matter. This is not optional or something that should be done along the way.
Jul 28 2014
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 timeI'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
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
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:At last somebody else who understands.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: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.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 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: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.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 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
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: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 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.[...] 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:Still, all the documentation do not looks good.On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu via Digitalmars-d wrote:Well correction: I think it's among the better documented modules in std. -- AndreiOn 7/26/14, 6:30 PM, w0rp wrote:"No, I'm not in denial! It can't be!!!"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
Aug 21 2014
On 07/27/2014 04:39 AM, Andrei Alexandrescu wrote:On 7/26/14, 6:30 PM, w0rp wrote:^~~~~~~~~~~~~~~~~~~ This actually tripped me up while speed-reading. :o) Intended?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! Imust be in denial... -- Andrei
Jul 28 2014
Am 27.07.2014 00:54, schrieb w0rp:http://w0rp.com:8010/library/index.htmlSince 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
On Sunday, 27 July 2014 at 16:32:15 UTC, Sönke Ludwig wrote:Am 27.07.2014 00:54, schrieb w0rp: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.http://w0rp.com:8010/library/index.htmlSince 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 28 2014
Am 29.07.2014 00:04, schrieb w0rp:On Sunday, 27 July 2014 at 16:32:15 UTC, Sönke Ludwig wrote: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/51Am 27.07.2014 00:54, schrieb w0rp: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.http://w0rp.com:8010/library/index.htmlSince 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.You can see some running examples on the site now. http://w0rp.com:8010/library/std.parallelism/ Obviously if it stays that way, some 301 redirects will have to be set up pointing from the old URLs to the new ones. I've been setting up a few as I go already.There is also a pending change for the current documentation that changes the current link style (balancedParens.html) to lowercase underscore notation (balanced_parens.html), so there will be a bunch of redirects already. One issue with this is that the new style will sometimes have ambiguous redirects to the canonical style (balancedParens) because it removes the case information, but I don't really see a way around that.I'll look at playing with the style of the documentation pages some more another evening. I've had a few ideas for improvements, and I obviously still need to include syntax highlighting. Is this the library which is being used on the live site now for that? https://code.google.com/p/google-code-prettify/That plus some modifications to add D support. But my plan was to use server side highlighting using Brian Schott's lexer in the future.
Jul 28 2014
On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote: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?I'll look at playing with the style of the documentation pages some more another evening. I've had a few ideas for improvements, and I obviously still need to include syntax highlighting. Is this the library which is being used on the live site now for that? https://code.google.com/p/google-code-prettify/That plus some modifications to add D support. But my plan was to use server side highlighting using Brian Schott's lexer in the future.
Jul 28 2014
Am 29.07.2014 00:54, schrieb w0rp:On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote: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.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?I'll look at playing with the style of the documentation pages some more another evening. I've had a few ideas for improvements, and I obviously still need to include syntax highlighting. Is this the library which is being used on the live site now for that? https://code.google.com/p/google-code-prettify/That plus some modifications to add D support. But my plan was to use server side highlighting using Brian Schott's lexer in the future.
Jul 29 2014
On Tuesday, 29 July 2014 at 08:27:40 UTC, Sönke Ludwig wrote:Am 29.07.2014 00:54, schrieb w0rp: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.On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote: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.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?I'll look at playing with the style of the documentation pages some more another evening. I've had a few ideas for improvements, and I obviously still need to include syntax highlighting. Is this the library which is being used on the live site now for that? https://code.google.com/p/google-code-prettify/That plus some modifications to add D support. But my plan was to use server side highlighting using Brian Schott's lexer in the future.
Jul 29 2014
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:Confusing sentence. Deception at it's finest. /sorryAm 29.07.2014 00:54, schrieb w0rp: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.On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote: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.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?I'll look at playing with the style of the documentation pages some more another evening. I've had a few ideas for improvements, and I obviously still need to include syntax highlighting. Is this the library which is being used on the live site now for that? https://code.google.com/p/google-code-prettify/That plus some modifications to add D support. But my plan was to use server side highlighting using Brian Schott's lexer in the future.
Jul 29 2014
Random guy here. I think the redesign is good. Populating the On This Page box with the function, enum etc. names would be nice. Preserving some form of site/page link navigation in the narrow mode is essential, be it switching to boxes at the top/bottom of the page or minimizing/maximizing the side bars. But maybe you're already working on that. Maybe the full width view could have a wider documentation body or dynamically scale up text, but it works fine as it is. As a tree style tabs plus side taskbar user I don't see all that much wasted space. Dynamically adjusting and being readable at half-width is a killer feature over D's current web docs, especially on desktops without workspaces.
Jul 30 2014
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
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
On 21/08/14 06:59, Hubert wrote:https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.pngI kind of like the structure of the page, but not the colors. -- /Jacob Carlborg
Aug 21 2014
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:First I wanna say that I've become a huge fan of D, and I hope one day I can replace all my creative projects with a D codebase. With that said, I do agree that D could use a redesign. I've not been monitoring this thread very closely, but the design suggestions I've seen so far has dissapointed me. Don't misunderstand me; the proposals look good, but they are in my opinion too conservative. Now I've given it a shot and created a first draft on how I imagine a future Dlang.org could/should look like, keep in mind that nothing is final yet: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the "market". I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. (I hope I haven't missed any earlier design proposal that already looks like this.)It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks.
Aug 21 2014
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
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
On Thursday, 21 August 2014 at 15:14:05 UTC, Kagamin wrote:On Thursday, 21 August 2014 at 12:09:38 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.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
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
On Thursday, 21 August 2014 at 15:16:52 UTC, Dicebot wrote:On Thursday, 21 August 2014 at 15:14:05 UTC, Kagamin wrote: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.On Thursday, 21 August 2014 at 12:09:38 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.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 24 2014
Thanks for the response! I do agree that the colors are way too "hot" (I've must've been quite tired when I submitted that mockup) Someone noted that the concept that I pitched had too much whitespace, which is a sentiment that I do not share. There's a lot of issues with the readability in the current design; way too wide columns just to name one thing. I must also completely disagree with the "90's anachronism" part. You may feel that a "Getting started" section and simplified link/navigation structure might be insulting or inefficient, but is the site supposed to cater to the entrenched D-practitioners? As long as the readability and the layout of the documentation is accurate and clear what does it matter to you? There's not any inherent value in complexity.
Aug 28 2014
On Friday, 29 August 2014 at 02:36:22 UTC, Hubert wrote:You may feel that a "Getting started" section and simplified link/navigation structure might be insulting or inefficient, but is the site supposed to cater to the entrenched D-practitioners? As long as the readability and the layout of the documentation is accurate and clear what does it matter to you? There's not any inherent value in complexity.I simply don't see good layout fitting into the same style. And having documentation sub-pages with totally different design is also pretty bad from the point of view of the visual style. If you can show any sketches how it can be used for more technical content I may be convinced :)
Aug 28 2014
On Fri, Aug 29, 2014 at 02:36:21AM +0000, Hubert via Digitalmars-d wrote:Thanks for the response! I do agree that the colors are way too "hot" (I've must've been quite tired when I submitted that mockup) Someone noted that the concept that I pitched had too much whitespace, which is a sentiment that I do not share. There's a lot of issues with the readability in the current design; way too wide columns just to name one thing. I must also completely disagree with the "90's anachronism" part. You may feel that a "Getting started" section and simplified link/navigation structure might be insulting or inefficient, but is the site supposed to cater to the entrenched D-practitioners? As long as the readability and the layout of the documentation is accurate and clear what does it matter to you? There's not any inherent value in complexity.I do not say that having a simplified link/navigation structure is insulting or inefficient. But I do say the simplification should be via categories that make sense. I.e., "click here to start / click here to watch completely irrelevant marketing video" makes no sense, whereas a breakdown like "News / Download / Get started with D / Reference documentation / Compiler specs / etc." makes sense. Content-less splash pages are, to me, completely worthless. A properly-designed front page with sensible top-level links to sensible categories, properly designed, will both look and work better. A proper design need not sacrifice content for appeal. T -- Never trust an operating system you don't have source for! -- Martin Schulze
Aug 28 2014
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote: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:https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.pngIt 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
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: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 :PIt 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
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 :PI 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
On Thursday, 21 August 2014 at 17:24:28 UTC, Théo Bueno wrote:I was referring to "Don't forget that programmers are hipsters" statement ;)Also please avoid personal insults :PI 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
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:Oh. Let me rephrase : Don't forget that programmers are undeclared hipsters :DI was referring to "Don't forget that programmers are hipsters" statement ;)Also please avoid personal insults :PI 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
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:ent ;)On Thursday, 21 August 2014 at 17:24:28 UTC, Th=C3=A9o Bueno wrote:I was referring to "Don't forget that programmers are hipsters" statem=Also please avoid personal insults :PI 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.=20 Oh. Let me rephrase : Don't forget that programmers are undeclared hipsters :DDuck 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
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
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
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.pngThat 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
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
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:First I wanna say that I've become a huge fan of D, and I hope one day I can replace all my creative projects with a D codebase. With that said, I do agree that D could use a redesign. I've not been monitoring this thread very closely, but the design suggestions I've seen so far has dissapointed me. Don't misunderstand me; the proposals look good, but they are in my opinion too conservative. Now I've given it a shot and created a first draft on how I imagine a future Dlang.org could/should look like, keep in mind that nothing is final yet: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the "market". I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. (I hope I haven't missed any earlier design proposal that already looks like this.)I'm not a fan of the colours and the general way it looks, but I do really like the three columns of text for the three big points. I'm not sure how to put that on a home page and keep some consistent navigation in place, so that would require some playing around with. You could maybe sacrifice sidebar navigation on the home page to allow enough space to fit in the text columns at 1024px width, I'm not sure. A few other people have mentioned fluid container widths. I actually know exactly what to do with that, I just haven't gotten around to doing it yet. I think I make some progress, but then life gets in the way a little bit. I'll come back to it soon and work a little more on the site.
Aug 21 2014
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the "market". I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. (I hope I haven't missed any earlier design proposal that already looks like this.)Sort of reminds me of Ocaml's webpage, but more minimalistic. I think a lot of good ideas could come from looking at other language's webpages, Haskell's new webpage is similar to Ocaml's but has less content(it's also not finished yet)
Aug 21 2014
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 =20It 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
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
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]Good advice that. :)Powered by Martian TechnologySarcasticRover is telling us "Do not come to Mars." Perhaps its commentary need censoring ;-)
Jul 04 2014
On Thursday, 3 July 2014 at 17:38:22 UTC, w0rp wrote:On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote: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.[I haven't had time to follow the entire thread, but] I like the design, it's a good starting point. Especially the integration of the logo. Nice and clean. (The current logo is just too bulky and clumsy, imo*) However, my experience tells me that we should wait with redesigning it until the technical issues/problems have been solved, e.g. the migration to vibe.d, which I'm in favor of (I've had good experiences with vibe.d so far), and the doc generation issue etc etc. Once that is out of the way, we can think about new designs.I've been focusing on getting a working site with vibe.d. Integrating the ddox document generator is a high priority for me right now, especially since I've finished a lot of work for formatting the changelog pages.Yours is very nice and "modern". However, we also have to take mobile devices (tablets, smartphones) into account and see how we can adapt to these (different layouts or one for all?).I used the Bootstrap framework, which I have also used in my day job. Bootstrap makes producing a responsive design pretty easy. I've been periodically testing pages on smaller screens. Firefox's 'reponsive design mode' helps a lot with this.Another issue is that we don't have to jump on any bandwagon (every time the "fashion" changes), we can roll our own design, one that fits the community's and the language's needs, regardless of what is trendy or "modern" at any given time (don't imitate, innovate!).There are many different designs you could produce. Many design choices are subjective, though not all of them. I think my goals for the work I've been doing are as follows. * Improve site navigation. * Improve display across different devices. * Improve the quality of text to make it easier to read. * Make it easier for newcomers to edit, to encourage contribution. * Run it all with D to tick a "official D site made in D" checkbox. There are others, but those are the important ones.
Jul 08 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? -- AleksandarWhat's up with this new website design ? Drafts looked good.
Dec 09 2014
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
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
On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:So, is it dead already ?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.
Jan 01 2015