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

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 ?

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.

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.

On 1/06/2014 7:49 a.m., w0rp wrote:
> After watching Andrei's keynote where he was asking for help, and
> noticing that there wasn't any proof of someone working on this, I took
> charge.
>
> http://w0rp.com:8010/
>
> That's the design in the form of a single page website running on my
> Linode. The source is available here.
>
> https://github.com/w0rp/new-dlang.org
>
> I would like to keep going with this and just redesign the whole
> website. A few points worth noting.
>
> * This is entirely a vibe.d website. (See the source.)
> * For pages, DDoc is replaced with diet templates.
> * I would still use ddox for generating library documentation.
> * The page is mostly held together with Bootstrap, which is very good.
> * The page is most of the way to being responsive (design sense), as it
> should be.
> * The module in the middle is missing, I'd use some future version of
> Nowak's drepl and put a REPL right there on the front page.
> * The logo is something I quickly put together with InkScape. Look at it
> as "please insert better logo here."
>
> I encourage the use of diet over DDoc because it is simpler to insert
> dynamic content in the page, especially so for vibe.d. The support for
> doing conditional things or loops based on any dynamic content we can
> think of is right there in vibe.d.

+1

> Now unfortunately, I have two major complaints, for vibe.d and D itself.
>
> For vibe.d, I can't think of a way to make changes to diet templates
> without recompiling the whole site. This doesn't seem so bad, given that
> compilation speed is very fast, but it builds up. This is because the
> process of experimenting with HTML becomes.
>
> 1. Make a change.
> 2. Recompile the whole program in a matter of seconds.
> 3. Refresh the browser window.
>
> Those seconds in between making a change and seeing the results really
> build up over time. It's probably hard to describe without trying it
> yourself, but trust me, it matters. This is the kind of thing I have
> recently fought against at work, and it was well worth it. I replaced a
> Compass filesystem monitor with an even slightly broken libsass CPython
> compiler which compiled SCSS based on modification times. The couple
> seconds of difference has definitely improved the day-to-day life of
> myself and the web designer I work with.
>
> This could be avoided if there was perhaps a way to rebuild diet
> templates at runtime. This could be enabled only for debug builds. So
> you could quickly make changes during development, and then compile
> everything statically for maximum speed for production.

The problem with diet is it compiles directly to D code, hence forth its not really possible at the moment.
However as I believe Sonke has said previous it is out of scope of Vibe. Its actually in the scope of Cmsed instead.

I have looked into doing just this, reloading of templates. And from what I can ascertain reliably we need shared library support. While this is doable upon Linux, it isn't on Windows. Until its available on Windows I will not use it.

My thread on the dub forum is here[0].
Basically I am also blocked by dub, to be able to grab all the previous templates ext. From libraries and push them into a findable place at runtime.

> The complaint I have for D is that too much memory is consumed for
> building D programs. The memory usage made it impossible for me to build
> the vibe.d site on my Linode, which the site above linked is running off
> of. The only way I was able to get the site to run on my Debian Wheezy
> server was to install a bunch of libraries from Debian testing, compile
> the program on my Arch Linux desktop, and then upload and run it on my
> server.

I personally allow for atleast 1.5 to 2gb of ram to build anything with D. Cmsed base package alone takes around 700mb. And thats with a LOT of CTFE work going on. I can only see that increasing.
So I'd like a way for dmd to utilize memory better even if it means slowing down for larger builds. For small builds the current way is great, just for larger we need alternative means.

> I'm not sure how to fix the issue myself, but something should be done
> to address this kind of issue. My Linode box has about 1GB of RAM with
> about 800MB free typically. Maybe I could have gotten things to build by
> increasing my swap space a little, I'm not sure.
>
> So, what does everyone else think?

Definitely looks nicer. But I must say it does feel a little clunky in some places (although don't ask how to fix, I don't know how to myself).

[0] http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/1404/

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

On Sat, 2014-05-31 at 20:40 +0000, w0rp via Digitalmars-d wrote:
> On Saturday, 31 May 2014 at 20:38:41 UTC, Meta wrote:
> > On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:
> >> On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:
> >>> The flat design looks nice, but I really dislike the choice of background colour. It's bland and clashes quite badly with the white of the menu and content box.
> >>
> >> For comparison, here's two images. One is the site with the background as the current gradient image, the second is the site with a background colour that matches your logo. Neither of them is particularly appealing, either, unfortunately.
> >
> > Whoops. http://imgur.com/oSHfFek,Mc81UYM
> 
> Yes, a darker background does look quite nice.

Contrast level is still a bit high though. The current dlang.org also
has this problem because of the use of white. I am not pushing dark grey
on light grey with spot colour (which is how Apple started out and still
use a lot) but something with less contrast might lead to a nice brand
imagery. Red, brown and black are clearly the base for a D brand, so
maybe washed out red-brown background rather than white. I haven't tried
this, it's just an idea – which may turn out to be rubbish.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

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.

On Sunday, 1 June 2014 at 05:46:57 UTC, Russel Winder via Digitalmars-d wrote:
>> The complaint I have for D is that too much memory is consumed for building D programs. The memory usage made it impossible for me to build the vibe.d site on my Linode, which the site above linked is running off of. The only way I was able to get the site to run on my Debian Wheezy server was to install a bunch of libraries from Debian testing, compile the program on my Arch Linux desktop, and then upload and run it on my server.
>
> Isn't the problem here that you are having to deploy in order to
> develop? Maybe I am just missing something, but it sounds as though
> there isn't actually a development workflow, just a create and release
> one.

Yes, that is a deployment issue. Deployment is a hot issue for me, for some reason. I tend to get annoyed if building software or deploying it is just a bit too tricky to do. So when they work, I like things like 'git pull origin master && dub build.'

> The Go website has it's faults, but it has a lot of good stuff,
> analogues of which would be well worth considering for a revised
> dlang.org. dlang.org may be a bit static and not of the currently
> fashionable style, but it has a brand image.

Branding does need to be worked on. Speaking of the site I'm working on... I would love to see something like the current D logo, but flatter. Then I think it needs a bit more colour in a few places. (We've adopted 'sort of blackish' and 'sort of redish' as brand colours. I also like D guy. I'd like to see a D guy which just fits naturally on the pages. It's kind of hard to tell what would unless you just put an image on the page and see what fits.

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.