## digitalmars.D - Redesign of dlang.org

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

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

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

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

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

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

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

So, what do you guys think?

-- Aleksandar

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

Hello,

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

Great!

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

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

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

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

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

So, what do you guys think?

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

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

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

-Steve

Apr 18 2014
On 4/18/14, 7:22 AM, Steven Schveighoffer wrote:
On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic
<aleksandar ruzicic.info> wrote:

Hello,

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

Great!

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

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

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

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

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

So, what do you guys think?

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

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

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

-Steve

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

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

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

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

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

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

[1] http://dlang.org/ddoc.html
[2] https://github.com/D-Programming-Language/dlang.org

Apr 18 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/18/14, 8:30 AM, David Gileadi wrote:
It does mean that the site is static HTML, so any dynamism needs to be
JS-only (and I think any efforts to make the pages largely JS-driven
would meet resistance).

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

Andrei

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu
wrote:
On 4/18/14, 8:30 AM, David Gileadi wrote:
It does mean that the site is static HTML, so any dynamism
needs to be
JS-only (and I think any efforts to make the pages largely
JS-driven
would meet resistance).

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

Andrei

I think that having vibe.d behind dlang.org would be great!

Apr 18 2014
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu
wrote:
On 4/18/14, 8:30 AM, David Gileadi wrote:
It does mean that the site is static HTML, so any dynamism
needs to be
JS-only (and I think any efforts to make the pages largely
JS-driven
would meet resistance).

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

Andrei

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

With more frequent updates, D-P-L/dlang.org would need to
properly use version branches to avoid having prerelease changes
but that's a change that's been needed for a long time. I'm not
sure if ddox was intended for something like this though (static
pages, as opposed to just documentation generation). SÃ¶nke would
probably have to weigh in and say if there is any real advantage
here. Making stuff "Powered by D" is always a nice change though.

Apr 18 2014
"Jacob Carlborg" <doob me.com> writes:
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu
wrote:

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

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

--
/Jacob Carlborg

Apr 19 2014
"alexhairyman" <alexhairyman gmail.com> writes:
On Friday, 18 April 2014 at 15:49:59 UTC, Andrei Alexandrescu
wrote:
On 4/18/14, 8:30 AM, David Gileadi wrote:
It does mean that the site is static HTML, so any dynamism
needs to be
JS-only (and I think any efforts to make the pages largely
JS-driven
would meet resistance).

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

Andrei

Going the vibe.d route would be great for advertising D as an all
encompassing language.

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:
As the guy who was mostly responsible for the current look and
feel of the website I can provide some insight into the effort
required. The website is built using DDoc[1], and anyone who
wants to change the look and feel will need to learn it. It's
not difficult. It does mean that the site is static HTML, so
any dynamism needs to be JS-only (and I think any efforts to
make the pages largely JS-driven would meet resistance).

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

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

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

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

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

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

and those "social" boxes so I forgot that thing exists).

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

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

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

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

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

[1] http://devdocs.io/

Apr 18 2014
On Friday, 18 April 2014 at 16:25:10 UTC, Aleksandar Ruzicic
wrote:
On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:
As the guy who was mostly responsible for the current look and
feel of the website I can provide some insight into the effort
required. The website is built using DDoc[1], and anyone who
wants to change the look and feel will need to learn it. It's
not difficult. It does mean that the site is static HTML, so
any dynamism needs to be JS-only (and I think any efforts to
make the pages largely JS-driven would meet resistance).

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

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

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

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

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

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

Thanks! I haven't worked with ddox yet but I'm looking forward to
try it out, it sure looks better than ddoc-based one.

Apr 18 2014
On 4/18/14, 9:25 AM, Aleksandar Ruzicic wrote:
On Friday, 18 April 2014 at 15:30:52 UTC, David Gileadi wrote:

[snip]

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

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

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

[snip]

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

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

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

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

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

[1] http://devdocs.io/

[1] https://github.com/rejectedsoftware/ddox

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:55:03 UTC, David Gileadi wrote:
another message) that would be fantastic. I think the mockup
you created is already a good direction but folks with
experience in UX, typography, responsive design etc. could
probably make dlang.org properly great.

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

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

Excellent!

And responsive design which scales well from desktops to tablets
and phones is a must (with support for hdpi screens of course).

Apr 18 2014
Aleksandar Ruzicic <aleksandar ruzicic.info> writes:
 To be honest, it looks no "better" than the current website. Basically
it's more windows-8-ish. But I don't think it's a significant improvement.

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

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

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

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

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

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

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

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

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

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

-Steve

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

-- Aleksandar

Apr 18 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 18 April 2014 15:22, Steven Schveighoffer via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On Fri, 18 Apr 2014 10:04:03 -0400, Aleksandar Ruzicic
<aleksandar ruzicic.info> wrote:

Hello,

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

Great!

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

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

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

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

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

So, what do you guys think?

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

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


Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 17:20:55 UTC, Iain Buclaw via
Digitalmars-d wrote:
Really?  To me it looks like the OP is mimicking Github
dccumentation pages.

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

But that mockup of homepage is not directly inspired by (or
trying to mimic) any website. I've just opened Photoshop chose
base colors and made layout that felt natural to me.

Apr 18 2014
"Lars T. Kyllingstad" <public kyllingen.net> writes:
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer
wrote:
I don't share your opinion that the web site need to be
"modern" to avoid warding off potential adopters. If they are
turned off of using a system programming language by a bland
(debatable) site look and feel, then I think there was really
something else bothering them.

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

Apr 19 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 Apr 2014 13:00, "Lars T. Kyllingstad via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer wrote:
I don't share your opinion that the web site need to be "modern" to

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

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

Apr 20 2014
"Lars T. Kyllingstad" <public kyllingen.net> writes:
On Sunday, 20 April 2014 at 08:38:25 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 19 Apr 2014 13:00, "Lars T. Kyllingstad via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On Friday, 18 April 2014 at 14:22:24 UTC, Steven Schveighoffer
wrote:
I don't share your opinion that the web site need to be
"modern" to

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

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

There's nothing wrong with it at all!  I was agreeing with Steve,
not arguing against him.  My point was that even though GCC is
one of the most popular software development tools in the world,
their site, like most of gnu.org, looks a bit... old school.
Which is just fine. :)

Apr 20 2014
"Christof Schardt" <Christof Schardt.info> writes:
"Aleksandar Ruzicic" <aleksandar ruzicic.info> schrieb im Newsbeitrag
news:mmoxalewsvwcgeaasvri forum.dlang.org...

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

Me too.

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

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

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

So, what do you guys think?

A good start!
+1

Apr 18 2014
captaindet <2krnk gmx.net> writes:
On 2014-04-18 09:04, Aleksandar Ruzicic wrote:
So, what do you guys think?

i like it.

Apr 18 2014
"Frustrated" <Who where.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
Hello,

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

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

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

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

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

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

So, what do you guys think?

-- Aleksandar

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

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

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 15:55:57 UTC, Frustrated wrote:
I like it too. A little cleaner/sharper. A little more
balanced. (centered, colors, etc)

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

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

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

Current design is good enough so that redesigning it is not
matter of urgency.

Apr 18 2014
"Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?

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

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

-Wyatt

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?

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

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

-Wyatt

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

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

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

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

-- Aleksandar

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

On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic wrote:
So, what do you guys think?

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

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

-Wyatt

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

Making something that works like this would be excellent:

http://forum.dlang.org/

-Steve

Apr 18 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 1:24 PM, Steven Schveighoffer wrote:
On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic
<aleksandar ruzicic.info> wrote:
I must respectfully disagree about retaining left justification.
I have 27'' monitor with resolution of 2560x1440 and left-aligned
websites are really hard to read!

Making something that works like this would be excellent:

http://forum.dlang.org/

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

Apr 19 2014
Jacob Carlborg <doob me.com> writes:
On 2014-04-19 23:06, Nick Sabalausky wrote:

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

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

--
/Jacob Carlborg

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

On 4/18/2014 1:24 PM, Steven Schveighoffer wrote:
On Fri, 18 Apr 2014 12:40:31 -0400, Aleksandar Ruzicic
<aleksandar ruzicic.info> wrote:
I must respectfully disagree about retaining left justification.
I have 27'' monitor with resolution of 2560x1440 and left-aligned
websites are really hard to read!

Making something that works like this would be excellent:

http://forum.dlang.org/

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

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

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

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

-Steve

Apr 21 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/21/2014 8:14 AM, Steven Schveighoffer wrote:
but I think having the font
grow when the window is expanded is somewhat useful.

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

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

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

Yea, I agree too. Luckily that's what max-width is for...although that
really SHOULD'VE been a browser setting/feature, not a per-page CSS
feature. But then, the browser developers these days will cram anything
and everything into CSS/HTML anymore (except, of course, anything that
actually gives the *user* any control over anything :/ )

Apr 21 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 21 April 2014 at 22:35:32 UTC, Nick Sabalausky wrote:
setting/feature, not a per-page CSS feature. But then, the
browser developers these days will cram anything and everything
into CSS/HTML anymore (except, of course, anything that
actually gives the *user* any control over anything :/ )

Then again, most users don't even know that there is a search
function built into the browserâ€¦ so they probably don'

Apr 21 2014
"John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
On Friday, 18 April 2014 at 16:10:03 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?

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

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

-Wyatt

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

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

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

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

-- Aleksandar

Or just a little switch in a corner somewhere to change the

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

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

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 3:45 AM, Aleksandar Ruzicic wrote:
On Friday, 18 April 2014 at 22:06:03 UTC, John Colvin wrote:
[snip]
Or just a little switch in a corner somewhere to change the

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

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

I don't think anyone's argued against the page layout itself being
centered (as long as you don't mean to center the text itself - that
would be one of the worst ways for text justification).

Apr 19 2014
"Jacob Carlborg" <doob me.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:

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

Agree. I think we should use Bootstrap. Then we can also get a

--
/Jacob Carlborg

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 08:35:32 UTC, Jacob Carlborg wrote:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:

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

Agree. I think we should use Bootstrap. Then we can also get a

--
/Jacob Carlborg

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

Apr 19 2014
Jacob Carlborg <doob me.com> writes:
On 2014-04-19 10:54, Aleksandar Ruzicic wrote:

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

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

Also, I prefer Sass over LESS :)

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

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

--
/Jacob Carlborg

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

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

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

Also, I prefer Sass over LESS :)

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

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

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

I have been using Foundation in last few projects and haven't
played with Bootstrap in a while but when I did I had to override
most of it's styles to achieve look I wanted (which resulted in a
significant amount of CSS/LESS needed just to remove Bootstrap's
styles).
I hope that things are better now..

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

Apr 19 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 April 2014 11:56, Aleksandar Ruzicic via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

I'm more a fan of Solr myself.

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

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 11:06:45 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 19 April 2014 11:56, Aleksandar Ruzicic via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

I'm more a fan of Solr myself.

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

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

Apr 19 2014
Jacob Carlborg <doob me.com> writes:
On 2014-04-19 13:09, Aleksandar Ruzicic wrote:

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

They're quire similar. Both builds on Lucene.

--
/Jacob Carlborg

Apr 20 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 19.04.2014 12:56, schrieb Aleksandar Ruzicic:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

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

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 12:04:11 UTC, SÃ¶nke Ludwig wrote:
Am 19.04.2014 12:56, schrieb Aleksandar Ruzicic:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

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

That's excellent news! Would it be possible to use it to search
through language reference too?

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:
On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

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

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

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

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote:
On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:
- There should be some visual indication of the search box besides the
text itself. It *looks* nice as you have it, but practically speaking
it'd be a bit awkward to not be able to see the box itself.

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

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

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

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

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

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

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 23:10:58 UTC, Nick Sabalausky wrote:
On 4/19/2014 5:57 PM, Aleksandar Ruzicic wrote:
On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky
wrote:
- There should be some visual indication of the search box
besides the
text itself. It *looks* nice as you have it, but practically
speaking
it'd be a bit awkward to not be able to see the box itself.

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

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

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

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

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

Yep, it' really nice UX element and it works without JS too! :)

Apr 19 2014
"Martin Nowak" <code dawg.eu> writes:
 But I like to add fallback (that works even without JS, but
better with JS) for that on old browsers which don't support
that feature.

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

Apr 23 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Wednesday, 23 April 2014 at 07:16:53 UTC, Martin Nowak wrote:
But I like to add fallback (that works even without JS, but
better with JS) for that on old browsers which don't support
that feature.

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

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

But I will leave all that cross-browser tweaking for last stage..

Apr 23 2014
"Martin Nowak" <code dawg.eu> writes:
On Saturday, 19 April 2014 at 10:56:07 UTC, Aleksandar Ruzicic
wrote:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

We can easily find better fonts :).

Apr 23 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Wednesday, 23 April 2014 at 07:28:51 UTC, Martin Nowak wrote:
On Saturday, 19 April 2014 at 10:56:07 UTC, Aleksandar Ruzicic
wrote:
Ok here's a mockup of search concept I would like to implement:

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

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

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

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

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

We can easily find better fonts :).

I'm not that unsatisfied with font faces (its Consolas nad
Calibri), more with sizes/spacing/colors.. But this is something
I will go over with a great graphics designer who will join me at
the start of May, so it will surely be much better.

Apr 23 2014
"Kagamin" <spam here.lot> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
I must respectfully disagree about retaining left justification.
I have 27'' monitor with resolution of 2560x1440 and
left-aligned websites are really hard to read!

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

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

[1] http://devdocs.io/

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

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 11:48:39 UTC, Kagamin wrote:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
I must respectfully disagree about retaining left
justification.
I have 27'' monitor with resolution of 2560x1440 and
left-aligned websites are really hard to read!

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

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

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

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

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

[1] http://devdocs.io/

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

Which browser do you use? I've used it only on Firefox (Aurora to
be precise) and it works flawlessly.
That was just an example of how convenient is to have
documentation filtered as you type. I'm not planning to make
"devdoc for d", just to provide nearly instantaneously results as
user types search query.

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 7:48 AM, Kagamin wrote:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic wrote:

[1] http://devdocs.io/

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

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

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

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 21:49:20 UTC, Nick Sabalausky wrote:
On 4/19/2014 7:48 AM, Kagamin wrote:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:

[1] http://devdocs.io/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But anyway, we're going slightly off-topic with this..

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

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

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

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

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

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

Suppose if it were as much as 100 bytes, which would be fairly large for
a cookie (mine total around 50 bytes or less when sent to the server),
then even 1000 requests (considerably larger than a typical session,
unless it's being overly-AJAXy, which would be a bigger performance
drain for both server/client than cookies anyway) is *still* just 100kB
which, for a modern server and that many requests, is nothing. It's
still *completely* dwarfed by all the other crap in the client's headers
alone, let alone the actual payload data being transferred back which,
in most cases, will be considerably larger still.

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote:
I must respectfully disagree about retaining left justification.
I have 27'' monitor with resolution of 2560x1440 and left-aligned
websites are really hard to read!

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

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

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

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

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

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

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

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 21:34:31 UTC, Nick Sabalausky wrote:
On 4/18/2014 12:40 PM, Aleksandar Ruzicic wrote:
I must respectfully disagree about retaining left

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

left-aligned
websites are really hard to read!

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

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

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

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

not too wide.
Current design has no limitation on line width which (at my

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

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

content
centered on larger monitors.

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

And left-justified makes it easier to distinguish individual
from one line down to the next line. Plus it does suffer from
those inconsistently-sized spaces.

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

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

It seems I'll have to implement this design proposal in HTML/CSS
to be able to better communicate design decisions.

Apr 19 2014
"Wyatt" <wyatt.epp gmail.com> writes:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
I have 27'' monitor with resolution of 2560x1440 and

Yeah, me too...

left-aligned websites are really hard to read!

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

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

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

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

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

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

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

-Wyatt

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 09:40:53 UTC, Wyatt wrote:
On Friday, 18 April 2014 at 16:40:32 UTC, Aleksandar Ruzicic
wrote:
I have 27'' monitor with resolution of 2560x1440 and

Yeah, me too...

left-aligned websites are really hard to read!

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

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

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

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

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

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

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

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

Oddly enough, Wikipedia's main page gets this right:
doesn't degrade gracefully to more narrow dimensions).

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

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

-Wyatt

Agreed. :)

Apr 21 2014
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
<snip>

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

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

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

So, what do you guys think?

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

That said, I also happen to think your design looks fantastic and
should replace the current one just based on its appearance and
big improvements to usability. It feels more professional. I'm
all for this change.

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 16:53:38 UTC, Brad Anderson wrote:
Even if it weren't better looking, just different, I'd say it
should be done. I'm of the opinion that every site, no matter
how good it looks, should go through redesigns periodically in
order to feel fresh and non-stagnant to repeat visitors. It's a
form of marketing that reassures users that something is being
actively developed.

I completely agree with this. There is a website I work on from
2007 which is completely redesigned every 1.5-2 years. There was
just once major feature addition, all other redesigns are done
for marketing reasons.

Apr 18 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 12:53 PM, Brad Anderson wrote:
Even if it weren't better looking, just different, I'd say it should be
done. I'm of the opinion that every site, no matter how good it looks,
should go through redesigns periodically in order to feel fresh and
non-stagnant to repeat visitors. It's a form of marketing that reassures
users that something is being actively developed.

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

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

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

That said, I also happen to think your design looks fantastic and should
replace the current one just based on its appearance and big
improvements to usability. It feels more professional. I'm all for this
change.


Apr 19 2014
Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4/20/14, Nick Sabalausky via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On a philosophical level, I *very* strongly disagree with this as I
think it amounts to deliberate enforcement of "screwing with shit that
ain't broke just for the sake of fucking around with it".

Yep. Also see how often MSDN breaks their links to their docs. Not
that they were ever descriptive, which is another bad UX example. E.g.
a page named "dd183370(v=vs.85).aspx".

Apr 19 2014
"Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
But, all this time D's official website somehow archaic look
kept troubling me. It reminds me of early 2000's design and I
really cannot associate this design with "modern" or "elegant",
what D really is.

Agreed.

So, what do you guys think?

Very nice! Huge improvement!

Apr 18 2014
"Kagamin" <spam here.lot> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png

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

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 18:53:47 UTC, Kagamin wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png

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

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

And it is not only Microsoft who are pushing flat as modern way
of doing design (but as far as I know they are one of firsts)..

Apr 18 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png

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

So, what do you guys think?

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

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

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 18:56:38 UTC, Ola Fosheim GrÃ¸stad
wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
http://krcko.net/dlang.org/dlang-home-draft1.png

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

So, what do you guys think?

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

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

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

Anyway, I have already said in one of previous posts that this is
just a mockup and that I will try to have real designer involved
(I'm not designer). I made this just to show direction in which I
think we should go with dlang.org.

Apr 18 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 18 April 2014 at 20:04:53 UTC, Aleksandar Ruzicic
wrote:
I wanted something that looks "professional", which is
something that can be associated with both serious community
and a corporation.

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

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

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

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

etc.

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 20:12:44 UTC, Ola Fosheim GrÃ¸stad
wrote:
On Friday, 18 April 2014 at 20:04:53 UTC, Aleksandar Ruzicic
wrote:
I wanted something that looks "professional", which is
something that can be associated with both serious community
and a corporation.

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

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

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

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

etc.

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

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

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

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

I also like ruby-lang.org and recently-redesigned php.net

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

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

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

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

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

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

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

Ola.

Apr 18 2014
"Kagamin" <spam here.lot> writes:
On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic
wrote:
I really like rust-lang.org, I was thinking of using it as a
base for design but decided against it because I don't want
dlang.org to be accused of ripping of rust-lang.org.

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

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

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

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 12:01:09 UTC, Kagamin wrote:
On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic
wrote:
I really like rust-lang.org, I was thinking of using it as a
base for design but decided against it because I don't want
dlang.org to be accused of ripping of rust-lang.org.

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

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

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

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

I've said few times that this is not metro style (I work with
metro apps daily) it's just flat (no semi-3D effect like shadows

Apr 21 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/21/14, 5:01 AM, Kagamin wrote:
On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic wrote:
I really like rust-lang.org, I was thinking of using it as a base for
design but decided against it because I don't want dlang.org to be
accused of ripping of rust-lang.org.

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

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

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu
wrote:
On 4/21/14, 5:01 AM, Kagamin wrote:
On Friday, 18 April 2014 at 20:28:07 UTC, Aleksandar Ruzicic
wrote:
I really like rust-lang.org, I was thinking of using it as a
base for
design but decided against it because I don't want dlang.org
to be
accused of ripping of rust-lang.org.

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

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

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

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

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

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

Relevant:
http://webtypography.net/toc/

Apr 22 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 22 April 2014 at 11:36:37 UTC, Lars T. Kyllingstad
wrote:
It annoys me that tried-and-true typographic best practices are
constantly and blatantly ignored by web designers.

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

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

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

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

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

http://www.spritzinc.com/

Apr 22 2014
"Kagamin" <spam here.lot> writes:
On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu
wrote:
Wait, are you advocating for text occupying the entire page
width, like a telex band? Aren't text lines difficult to follow
from the right side to the continuing left side? -- Andrei

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

Apr 22 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/22/14, 3:32 AM, Kagamin wrote:
On Monday, 21 April 2014 at 15:05:57 UTC, Andrei Alexandrescu wrote:
Wait, are you advocating for text occupying the entire page width,
like a telex band? Aren't text lines difficult to follow from the
right side to the continuing left side? -- Andrei

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

Andrei

Apr 22 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu
wrote:
On 4/22/14, 3:32 AM, Kagamin wrote:
What's problem with entire page width? I don't remember
difficulty
reading w3c docs or gcc docs or linux man pages even when they
occupy
the entire page width.

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

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

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

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

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

Apr 22 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/22/2014 4:39 PM, "Ola Fosheim GrÃ¸stad"

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

Man do I REALLY wish movie makers and game devs would at least TRY to

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

In just the last decade, it's become absurdly common for dialog to be
*quieter* than sound effects and background music. Insane.

Apr 22 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/22/14, 1:39 PM, "Ola Fosheim GrÃ¸stad"
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:
On 4/22/14, 3:32 AM, Kagamin wrote:
What's problem with entire page width? I don't remember difficulty
reading w3c docs or gcc docs or linux man pages even when they occupy
the entire page width.

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

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

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

I don't understand the motivation of this quip.

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

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

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

Strawman. I'm not advocating for fixed width.

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

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

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

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

Andrei

Apr 22 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu
wrote:
Trying to be clever? Obviously not.

I don't understand the motivation of this quip.

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

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

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

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

Anyway, you guys are taking this process in reverse. You should
functionality, then marginal design, then figure out what you
need in addition in terms of styling.

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

A redesign ought to:

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

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

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

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

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

Ola.

Apr 23 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 3:13 AM, "Ola Fosheim GrÃ¸stad"
On Wednesday, 23 April 2014 at 03:20:18 UTC, Andrei Alexandrescu wrote:
Trying to be clever? Obviously not.

I don't understand the motivation of this quip.

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

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

Apr 23 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 16:13:42 UTC, Andrei Alexandrescu
wrote:
On 4/23/14, 3:13 AM, "Ola Fosheim GrÃ¸stad"

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

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

In most contexts that will be taken as a RTFM response, as in:
Â«why didn't you search for this yourself?Â»

Apr 23 2014
"Kagamin" <spam here.lot> writes:
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu
wrote:

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

Apr 23 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 4:30 AM, Kagamin wrote:
On Tuesday, 22 April 2014 at 20:01:27 UTC, Andrei Alexandrescu wrote:

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

Maybe Google personalized my search, but the first hit is
-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.

points to a few studies concluding that 50-75 cpl (characters per line)
would be indicated for web design.

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

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

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

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

And so on and so forth.

====

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

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

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

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

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

Andrei

Apr 23 2014
"Dicebot" <public dicebot.lv> writes:
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu
wrote:
... first hit is
-digital-vs-printed
pointing to a study indicating 95 characters per line as
optimal for on-screen reading comprehension. The subjective
preferences, however, was biased toward smaller numbers.

a few studies concluding that 50-75 cpl (characters per line)
would be indicated for web design.

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

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

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

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

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

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

I don't know. It's a good question and an interesting challenge. -- Andrei

Apr 23 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Apr 23, 2014 at 04:28:30PM +0000, Dicebot via Digitalmars-d wrote:
[...]
Gosh now I finally know what researches to blame for my eyes bleeding
upon most web site restylings (Facebook *caugh-caugh*). If anything it
just shows that overall reading skills are decreasing and no one care
about visitors with small fonts (me).

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

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

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

T

--
Time flies like an arrow. Fruit flies like a banana.

Apr 23 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote:
On the contrary, I find almost all websites have broken layouts because
I enforce a minimal font size of 16pt (I have a high-resolution screen)
-- they insist on font sizes that are far too small.

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

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

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

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

Some day I'm going to pull a tape measure between my eyes and my monitor, and
get some glasses optimized for that distance.

Apr 23 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/23/2014 2:12 PM, Walter Bright wrote:
On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote:
On the contrary, I find almost all websites have broken layouts because
I enforce a minimal font size of 16pt (I have a high-resolution screen)
-- they insist on font sizes that are far too small.

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

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

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

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

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

Apr 23 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Apr 23, 2014 at 05:32:00PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 4/23/2014 2:12 PM, Walter Bright wrote:
On 4/23/2014 10:02 AM, H. S. Teoh via Digitalmars-d wrote:
On the contrary, I find almost all websites have broken layouts
because I enforce a minimal font size of 16pt (I have a
high-resolution screen) -- they insist on font sizes that are far
too small.

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

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

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

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

Any examples?

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

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

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

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

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

T

--
"No, John.  I want formats that are actually useful, rather than
over-featured megaliths that address all questions by piling on
ridiculous internal links in forms which are hideously over-complex." --
Simon St. Laurent on xml-dev

Apr 23 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:
On Wed, Apr 23, 2014 at 05:32:00PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
I certainly won't disagree that small fonts can be hard to read, but
on the other end, I've seen a lot of newer websites with gigantic
fonts, and I find that painful to read as well.

Any examples?

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

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

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

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

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

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

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

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

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

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

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

Of course, I am aware that #000000/#FFFFFF can be a bit too much
contrast, so you often want something that's just a really dark grey.
But still, a lot of sites take the softened-contrast thing too far.

Apr 24 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:
I agree. Unfortunately though, browsers haven't always has
reasonable defaults, so people had to work around, so now it's
all pretty much screwed.

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

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

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

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

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

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

I've recently seen some academic research PDF's where the font is so small that
even if I go full screen on them they are very hard to read. I don't get the
reason for doing this. Are they trying to save paper or something?

Apr 24 2014
"bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

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

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

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

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

Bye,
bearophile

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

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

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

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

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

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

[...]

You mean, they're trying to save on pages? I don't think the journal
cost of printing too many pages.

T

--
It is not the employer who pays the wages. Employers only handle the money. It
is the customer who pays the wages. -- Henry Ford

Apr 24 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 10:07 PM, H. S. Teoh via Digitalmars-d wrote:
I don't like wide screens that much, actually. I still prefer 4x3 aspect
ratio. I kinda agree with Nick that wide screens are more like
half-height screens. :-P

I've even seen companies actually trying to sell ~2:1 abominations. Even
movies (which are perfectly fine in 16:9) are painful to watch in that
god-awful ratio - even made "Batman Begins" difficult to watch. Luckily
nobody seems dumb enough to reward those devices with actual purchases.

Apr 24 2014
Walter Bright <newshound2 digitalmars.com> writes:
On 4/24/2014 6:54 PM, bearophile wrote:
Some combinations of PDF readers and PDF files support reflow, so later you can
also increase the zoom. Another solution is to buy a wider screen, now even
wide
ones are kind of cheap.

Wider ones won't help. You'd need a taller one.

Apr 24 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 9:54 PM, bearophile wrote:
Walter Bright:
I don't get the reason for doing this. Are they trying to save paper
or something?

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

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

Apr 24 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 11:46:16PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 4/24/2014 9:54 PM, bearophile wrote:
Walter Bright:
I don't get the reason for doing this. Are they trying to save paper
or something?

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

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

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

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

T

--
The trouble with TCP jokes is that it's like hearing the same joke over and
over.

Apr 24 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/25/2014 12:00 AM, H. S. Teoh via Digitalmars-d wrote:
OTOH, I believe journals nowadays actually give you a LaTeX template
that you're supposed to follow, and they greatly frown upon submissions
that don't conform to that template. So people are less likely to fiddle
with stuff that they normally would otherwise.

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

Apr 24 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 25, 2014 at 12:24:47AM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 4/25/2014 12:00 AM, H. S. Teoh via Digitalmars-d wrote:
OTOH, I believe journals nowadays actually give you a LaTeX template
that you're supposed to follow, and they greatly frown upon
submissions that don't conform to that template. So people are less
likely to fiddle with stuff that they normally would otherwise.

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

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

publisher_template.tex:

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

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

my_macros.tex:

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

content.tex:

...	% put actual article body here

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

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

T

--
Marketing: the art of convincing people to pay for what they didn't need
before which you can't deliver after.

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

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

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

Actually, I just meant:

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

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

Obviously not quite as quick and reliable as what a programmer might do,
but still pretty damn trivial, and well within the abilities of any
author. In fact, it's pretty much what nearly any "average Joe with MS
Word" would do without even being told. And they manage to get by fine
(much to my puzzlement, sometimes ;) ).

Apr 25 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
Another thing that kills me about the new "big picture up top,
scroll to gigantic say-nothing text below" fad....

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

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

<a href="this-makes-me-angry-because-it-sux">Hatred.</a>

Apr 24 2014
"Kagamin" <spam here.lot> writes:
On Thursday, 24 April 2014 at 08:17:15 UTC, Nick Sabalausky wrote:
As if <b> hasn't always implied the semantics of "emphasis"
anyway...not that anyone's ever had any real use for semantic
"which text is emphasized?" for any purpose besides "Should
this text be rendered in bold/italic or not?"

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

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

On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:
I agree. Unfortunately though, browsers haven't always has
reasonable defaults, so people had to work around, so now it's
all pretty much screwed.

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

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

Apr 24 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 9:59 AM, Kagamin wrote:
On Thursday, 24 April 2014 at 08:17:15 UTC, Nick Sabalausky wrote:
As if <b> hasn't always implied the semantics of "emphasis"
anyway...not that anyone's ever had any real use for semantic "which
text is emphasized?" for any purpose besides "Should this text be
rendered in bold/italic or not?"

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

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

Markdown:

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

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

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

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

Apr 24 2014
"Kagamin" <spam here.lot> writes:
On Thursday, 24 April 2014 at 21:48:46 UTC, Nick Sabalausky wrote:
Markdown:

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

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

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

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

It wouldn't prevent using custom styles, it would enable use of
user preferences without rolling custom setting manager, what
Alexandar is going to do.

Apr 25 2014
On Wednesday, 23 April 2014 at 16:28:32 UTC, Dicebot wrote:
*caugh-caugh*). If anything it just shows that overall reading
skills are decreasing and no one care about visitors with small
fonts (me). But current HTML/CSS standards don't provide way to
express sizes as percentage of screen width (as opposed to page
window width), do they?

Javascript libraries fill this gap:
http://simplefocus.com/flowtype/

Apr 23 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 23/04/2014 5:28 PM, Dicebot wrote:
Gosh now I finally know what researches to blame for my eyes bleeding
upon most web site restylings (Facebook *caugh-caugh*).

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

A...

Apr 24 2014
"Dicebot" <public dicebot.lv> writes:
On Thursday, 24 April 2014 at 08:06:18 UTC, Alix Pexton wrote:
On 23/04/2014 5:28 PM, Dicebot wrote:
Gosh now I finally know what researches to blame for my eyes
bleeding
upon most web site restylings (Facebook *caugh-caugh*).

are too small?

A...

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

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

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

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

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

Apr 24 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 08:21:04PM +0100, Alix Pexton via Digitalmars-d wrote:
On 24/04/2014 9:44 AM, Dicebot wrote:
Considering the very same size 9 fonts are used as default everywhere
else in my desktop system and it feels just fine.. yeah, you must be
right. It must be small font and not weirdly scaled UI with 2/3 of
screen space blank. Sure.

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

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

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

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

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

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

T

--
Verbing weirds language. -- Calvin (& Hobbes)

Apr 24 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/24/2014 3:40 PM, H. S. Teoh via Digitalmars-d wrote:
In an ideal world, the webserver simply serves the content, and the
browser is the one that decides how to present it -- and the user
decides how the browser should present it. Ultimately, the user should
be in charge.

That's exactly how HTML used to work, but then the print folk and
graphic designers came in and demanded total control.

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

We must just be opposites.

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

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

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

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

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

A...

Apr 24 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu
wrote:
So I'd dlang.org to foster a behavior depending on the
available real estate, as follows:

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

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

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

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

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

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

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

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

Waste of time.

Apr 23 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/14, 1:53 PM, "Ola Fosheim GrÃ¸stad"
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu wrote:
So I'd dlang.org to foster a behavior depending on the available real
estate, as follows:

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

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

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

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

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

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

I'm talking averages.

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

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

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

Uhm...

Waste of time.

I doubt it.

Andrei

Apr 23 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 23 April 2014 at 23:25:43 UTC, Andrei Alexandrescu
wrote:
1. you don't use a monofont and have to figure out what "cpl"
is in "em"
or "rem".

I'm talking averages.

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

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

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

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

Uhm...

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

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

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

Waste of time.

I doubt it.

You are better off setting something reasonable, test, modify,
iterate. And if needed you can always provide a stylesheet
switcher (takes 15 minute to implement).

Apr 24 2014
"Kagamin" <spam here.lot> writes:
On Wednesday, 23 April 2014 at 16:13:37 UTC, Andrei Alexandrescu
wrote:
So I'd dlang.org to foster a behavior depending on the
available real estate, as follows:

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

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

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

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

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

I'm not against 100 cpl, I'm against page width and 1300px, that
are much less meaningful values. In fact, that WCAG page displays
for me at full page width and 100 cpl, and it has small
stylesheet. Why not let user choose? All that complication also
results in overblown stylesheets, which are unmanageable without
a CSS preprocessor (yikes, just what they have there?). Why solve
problem you created yourself?

Apr 25 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 4:12 PM, "Ola Fosheim GrÃ¸stad"
1. visitors are likely to be familiar with one of those
2. they might have figured out something that works
3. you want to do at least what they do, but better

Good points.

IMO:

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

Too black-and-white.

http://golang.org/

Too cluttered *and* too plain-white.

https://www.dartlang.org/

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

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

https://www.python.org/

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

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 6:52 PM, Nick Sabalausky wrote:
On 4/18/2014 4:12 PM, "Ola Fosheim GrÃ¸stad"

> https://www.python.org/

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

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

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 2:56 PM, "Ola Fosheim GrÃ¸stad"
Nice initiative, but the top bar looks a lot like adobe.com . I think
something less corporate would be more suitable. What are you trying to
communicate? A community or a corporation?

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

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

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

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

Apr 19 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Saturday, 19 April 2014 at 22:38:31 UTC, Nick Sabalausky wrote:
I had a brief thought of that too, but I quickly dismissed it
because it really *isn't* corporate-looking...

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

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

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

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

Apr 20 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Just to stating some basic observations to avoid noise.

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

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

primary target is people who stumble over dlang.org while

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

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

Apr 20 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
I just had a non-alcohol beer, so I think I'll rant some more
while I'm at it:

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

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

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

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

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

As an example I'll point out that this norwegian site has a very

http://www.arngren.net/

It is not because it has wonderful designâ€¦ ;-)

Apr 20 2014
"Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 20 Apr 2014 03:33:46 -0400, Ola Fosheim Gr=C3=B8stad  =

It does not peek my interest

Sorry, don't take this the wrong way, it's my OCD, not your fault ;)

But it's "pique"

-Steve

Apr 21 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 21 April 2014 at 12:21:20 UTC, Steven Schveighoffer
wrote:
Sorry, don't take this the wrong way, it's my OCD, not your
fault ;)

Of course it is my fault! I always thought it was "peak", thanks
for extending my vocabulary. Now I have figure out not only when
to use "peek" or "peak", but also have to consider "pique"â€¦ :-/

But it's "pique"

In my own tounge it sounds like the norwegian word for male
genitalsâ€¦ but I am liberal. I can say "pique":

P I Q U E !

(That's frenchâ€¦?)

Apr 21 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 10:04 AM, Aleksandar Ruzicic wrote:
I have also tried to design something myself (although I'm not a
designer) and this is what I came up with:

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

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

So, what do you guys think?

I'm normally very skeptical and critical of "staying modern" (and
regarding someone's mention of Win8 - I find Win8 downright UGLY) -
However...I really like your design, quite a lot.

As long as it's:

- A normal reflowing layout (not a static fixed-width one or an
auto-rescaling one)

- Doesn't require JS (optional JS enhancements are fine)

- Works reasonably well on mobile *including* a complete and total lack
of that "no zooming allowed" abomination that seems so popular these
days (As far as I'm concerned, full user-controlled scaling is
*mandatory* for good usability on tiny hand-held devices, especially on
these "modern" capacitive ones incapable of registering presses from
anything more accurate than a blunt finger - or for anyone with less
than 20/20 eyesight)

Apr 18 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/18/2014 6:07 PM, Nick Sabalausky wrote:
As long as it's:

[...]

Meant to say: Nothing against the current design, but as long as yours
is (those things), then I'd be very happy to see your design used.

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote:
On 4/18/2014 10:04 AM, Aleksandar Ruzicic wrote:
I have also tried to design something myself (although I'm not
a
designer) and this is what I came up with:

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

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

So, what do you guys think?

I'm normally very skeptical and critical of "staying modern"
(and regarding someone's mention of Win8 - I find Win8
downright UGLY) - However...I really like your design, quite a
lot.

As long as it's:

- A normal reflowing layout (not a static fixed-width one or an
auto-rescaling one)

Of course.

- Doesn't require JS (optional JS enhancements are fine)

I was told you would oppose usage of JavaScript. :)
But as I've said already I plan on using JavaScript to enhance
things a bit only, site would function normally with JavaScript
unavailable/disabled.

- Works reasonably well on mobile *including* a complete and
total lack of that "no zooming allowed" abomination that seems
so popular these days (As far as I'm concerned, full
user-controlled scaling is *mandatory* for good usability on
tiny hand-held devices, especially on these "modern" capacitive
ones incapable of registering presses from anything more
accurate than a blunt finger - or for anyone with less than
20/20 eyesight)

Agreed. And it shouldn't just work reasonably well on mobile, it
must work flawlessly well :)

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 3:48 AM, Aleksandar Ruzicic wrote:
On Friday, 18 April 2014 at 22:08:13 UTC, Nick Sabalausky wrote:
As long as it's:

- A normal reflowing layout (not a static fixed-width one or an
auto-rescaling one)

Of course.

Cool.

- Doesn't require JS (optional JS enhancements are fine)

I was told you would oppose usage of JavaScript. :)

Heh, yea, I'm kinda well-known for that 'round these parts ;)

But as I've said already I plan on using JavaScript to enhance things a
bit only, site would function normally with JavaScript
unavailable/disabled.

Yea, that's cool. Honestly, even I do that too.

- Works reasonably well on mobile *including* a complete and total
lack of that "no zooming allowed" abomination that seems so popular
these days (As far as I'm concerned, full user-controlled scaling is
*mandatory* for good usability on tiny hand-held devices, especially
on these "modern" capacitive ones incapable of registering presses
from anything more accurate than a blunt finger - or for anyone with
less than 20/20 eyesight)

Agreed. And it shouldn't just work reasonably well on mobile, it must
work flawlessly well :)

Heh, personally, I think working "flawlessly well" on mobile pretty much
requires a PalmOS device (long since defunct), but that's a whole other
twenty rants and would only make me feel old ;)

Apr 19 2014
1100110 <0b1100110 gmail.com> writes:
On 4/18/14, 9:04, Aleksandar Ruzicic wrote:
Hello,

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

[snip]
So, what do you guys think?

-- Aleksandar

I REALLY like the new look.  I think it's about time to change the
website up a little bit for the reasons listed above.

It looks 'clean'.  Go for it!

Apr 18 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:
On 4/18/14, 9:04, Aleksandar Ruzicic wrote:
Hello,

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

[snip]
So, what do you guys think?

-- Aleksandar

I REALLY like the new look.  I think it's about time to change
the website up a little bit for the reasons listed above.

It looks 'clean'.  Go for it!

Thanks! I'm planning to start working on this as soon as I get
approval from Walter/Andrei, and as most of people who answered
here are agreed that redesign would be a good thing I hope they
wouldn't oppose..

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote:
On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:
It looks 'clean'.  Go for it!

Thanks! I'm planning to start working on this as soon as I get approval
from Walter/Andrei, and as most of people who answered here are agreed
that redesign would be a good thing I hope they wouldn't oppose..

Although I empathize with not wanting to put the full work into
something if there's a chance it may just get rejected at the last step,
this is unfortunately the sort of thing that really needs to be in a
full working pull request before you're likely to get any final official
approval. Not getting an outright up-front objections is kinda the
closest thing D has to pre-approval for large changes like this.

Apr 19 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 23:21:15 UTC, Nick Sabalausky wrote:
On 4/19/2014 4:02 AM, Aleksandar Ruzicic wrote:
On Friday, 18 April 2014 at 23:50:56 UTC, 1100110 wrote:
It looks 'clean'.  Go for it!

Thanks! I'm planning to start working on this as soon as I get
approval
from Walter/Andrei, and as most of people who answered here
are agreed
that redesign would be a good thing I hope they wouldn't
oppose..

Although I empathize with not wanting to put the full work into
something if there's a chance it may just get rejected at the
last step, this is unfortunately the sort of thing that really
needs to be in a full working pull request before you're likely
to get any final official approval. Not getting an outright
up-front objections is kinda the closest thing D has to
pre-approval for large changes like this.

Ok then. Given that I haven't received up-front rejections I'll
start working on this and hope it wouldn't be in vain. :)

Apr 19 2014
Martin Nowak <code dawg.eu> writes:
On 04/20/2014 01:21 AM, Nick Sabalausky wrote:
Although I empathize with not wanting to put the full work into
something if there's a chance it may just get rejected at the last step,
this is unfortunately the sort of thing that really needs to be in a
full working pull request before you're likely to get any final official
approval. Not getting an outright up-front objections is kinda the
closest thing D has to pre-approval for large changes like this.

Getting more feedback during early development would help.
Not sure how to get there, there is little traffic on dmd-internals,
DIPs rarely result from collaboration and pull requests only allow to
criticize almost finished work.

Apr 24 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
I'm planning to start working on this as soon as I get approval
from Walter/Andrei, and as most of people who answered here are agreed
that redesign would be a good thing I hope they wouldn't oppose..

Let's do it. Thank you very much! -- Andrei

Apr 20 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu
wrote:
On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
I'm planning to start working on this as soon as I get approval
from Walter/Andrei, and as most of people who answered here
are agreed
that redesign would be a good thing I hope they wouldn't
oppose..

Let's do it. Thank you very much! -- Andrei

Great! I'll start tonight! :)

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu
wrote:
On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
I'm planning to start working on this as soon as I get approval
from Walter/Andrei, and as most of people who answered here
are agreed
that redesign would be a good thing I hope they wouldn't
oppose..

Let's do it. Thank you very much! -- Andrei

Just one question, would it be okay to depend on node.js/npm to
manage dependencies (i.e. CSS/JS frameworks) and build CSS/JS
files?

As I'd use Sass for styling, which must be translated to CSS (I'd
use node-sass package witch doesn't require ruby), and browserify
to have Common-JS modules..

Apr 21 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/21/14, 8:48 AM, Aleksandar Ruzicic wrote:
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu wrote:
On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
I'm planning to start working on this as soon as I get approval
from Walter/Andrei, and as most of people who answered here are agreed
that redesign would be a good thing I hope they wouldn't oppose..

Let's do it. Thank you very much! -- Andrei

Just one question, would it be okay to depend on node.js/npm to manage
dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

Ionno. Not an expert, but I'd say the fewer dependencies the better. Add
them only if it's onerously hard to get work done without and/or if
their payoff is large.

As I'd use Sass for styling, which must be translated to CSS (I'd use
node-sass package witch doesn't require ruby), and browserify to have
Common-JS modules..

I think you should be fine with ddoc macros instead of Sass.

Andrei

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 18:35:04 UTC, Andrei Alexandrescu
wrote:
On 4/21/14, 8:48 AM, Aleksandar Ruzicic wrote:
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu
wrote:
On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
I'm planning to start working on this as soon as I get
approval
from Walter/Andrei, and as most of people who answered here
are agreed
that redesign would be a good thing I hope they wouldn't
oppose..

Let's do it. Thank you very much! -- Andrei

Just one question, would it be okay to depend on node.js/npm
to manage
dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

Ionno. Not an expert, but I'd say the fewer dependencies the
better. Add them only if it's onerously hard to get work done
without and/or if their payoff is large.

Understood.

As I'd use Sass for styling, which must be translated to CSS
(I'd use
node-sass package witch doesn't require ruby), and browserify
to have
Common-JS modules..

I think you should be fine with ddoc macros instead of Sass.

Andrei

I'm not sure if it is smart to use simple text macro processing
system as a replacement for full-featured DSL such is Sass. And I
don't think that some features available (and really useful!) in
Sass are even possible with Ddoc. For example branching with  if,
composing of various style sets to optimal CSS (Sass has  extend
directive for this).
Also, Ddoc can't minify resulting CSS which is something that is
considered good practice (serve gzipped minified JS/CSS), so some
external tool must be used for that. With node-sass we can get
all that and more (i.e. source maps)..

Apr 21 2014
On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
I'm not sure if it is smart to use simple text macro processing system
as a replacement for full-featured DSL such is Sass. And I don't think
that some features available (and really useful!) in Sass are even
possible with Ddoc. For example branching with  if, composing of various
style sets to optimal CSS (Sass has  extend directive for this).
Also, Ddoc can't minify resulting CSS which is something that is
considered good practice (serve gzipped minified JS/CSS), so some
external tool must be used for that. With node-sass we can get all that
and more (i.e. source maps)..

A little searching turned up libsass.org which apparently is the native
library that node.js uses for its implementation. So if there's an
objection to full node.js (or if vibe.d is used) then perhaps the native
library would do.

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:
On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
I'm not sure if it is smart to use simple text macro
processing system
as a replacement for full-featured DSL such is Sass. And I
don't think
that some features available (and really useful!) in Sass are
even
possible with Ddoc. For example branching with  if, composing
of various
style sets to optimal CSS (Sass has  extend directive for
this).
Also, Ddoc can't minify resulting CSS which is something that
is
considered good practice (serve gzipped minified JS/CSS), so
some
external tool must be used for that. With node-sass we can get
all that
and more (i.e. source maps)..

A little searching turned up libsass.org which apparently is
the native library that node.js uses for its implementation. So
if there's an objection to full node.js (or if vibe.d is used)
then perhaps the native library would do.

Yep, forgot to mention that libsass (used by node-sass) is
cross-platform C library. Thanks!

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 20:12:31 UTC, David Gileadi wrote:
On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
I'm not sure if it is smart to use simple text macro
processing system
as a replacement for full-featured DSL such is Sass. And I
don't think
that some features available (and really useful!) in Sass are
even
possible with Ddoc. For example branching with  if, composing
of various
style sets to optimal CSS (Sass has  extend directive for
this).
Also, Ddoc can't minify resulting CSS which is something that
is
considered good practice (serve gzipped minified JS/CSS), so
some
external tool must be used for that. With node-sass we can get
all that
and more (i.e. source maps)..

A little searching turned up libsass.org which apparently is
the native library that node.js uses for its implementation. So
if there's an objection to full node.js (or if vibe.d is used)
then perhaps the native library would do.

Oh, I forgot to mention that I'm not advocating the use of
node.js to serve dlang.org (I'm all for vibe.d route!), just to
use node.js packages I'm used to (i.e. gulp[1], gulp-sass[2] and
gulp-browserify[3]) that ease me in working with front-end
projects.

[1] https://www.npmjs.org/package/gulp
[2] https://www.npmjs.org/package/gulp-sass
[3] https://www.npmjs.org/package/gulp-browserify

Apr 21 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/21/14, 12:38 PM, Aleksandar Ruzicic wrote:
I'm not sure if it is smart to use simple text macro processing system
as a replacement for full-featured DSL such is Sass. And I don't think
that some features available (and really useful!) in Sass are even
possible with Ddoc.

Well you'd be surprised. But the same guideline applies - the tool needs
to offer enough payoff to justify the dependency.

this point. We depend on dpl-docs already, and the tool was difficult to
install and broke from one dmd release to the next. SÃ¶nke was nice and
proactive about it, but he's an active member of the community. If we
find issues with tooling coming from the outside - and we will - we're
on our own. It would help if many people in the community are fluent
with them.

Adding a tool right now that has overlapping functionality with
ddoc/dpl-docs, and that is relatively unknown within the community
sounds like a tall order.

Andrei

Apr 21 2014
Jacob Carlborg <doob me.com> writes:
On 21/04/14 23:23, Andrei Alexandrescu wrote:

this point. We depend on dpl-docs already, and the tool was difficult to
install and broke from one dmd release to the next. SÃ¶nke was nice and
proactive about it, but he's an active member of the community. If we
find issues with tooling coming from the outside - and we will - we're
on our own. It would help if many people in the community are fluent
with them.

I've used Sass a lot. Although not via node.

Adding a tool right now that has overlapping functionality with
ddoc/dpl-docs, and that is relatively unknown within the community
sounds like a tall order.

Sass doesn't overlap with ddoc.

--
/Jacob Carlborg

Apr 21 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/21/14, 11:51 PM, Jacob Carlborg wrote:
On 21/04/14 23:23, Andrei Alexandrescu wrote:

this point. We depend on dpl-docs already, and the tool was difficult to
install and broke from one dmd release to the next. SÃ¶nke was nice and
proactive about it, but he's an active member of the community. If we
find issues with tooling coming from the outside - and we will - we're
on our own. It would help if many people in the community are fluent
with them.

I've used Sass a lot. Although not via node.

Good to know, thanks.

Adding a tool right now that has overlapping functionality with
ddoc/dpl-docs, and that is relatively unknown within the community
sounds like a tall order.

Sass doesn't overlap with ddoc.

I'm clearly outta my depth here, basing myself off of giving
http://sass-lang.com/guide a couple minutes. From what I can tell here's
how ddoc matches up sass features:

Pre-processing: yes
Variables: yes
Nesting: no
Partials, Import: somewhat (by passing several ddoc files to dmd)
Mixins: yes
Extend/Inheritance: no
Operators: no

I'm glad to see a revamp of dlang.org happening. Again if the added
dependencies carelessly and only for minor convenience.

recently. Is it helping/competing with the new tools you plan to add?

Andrei

Apr 22 2014
Jacob Carlborg <doob me.com> writes:
On 2014-04-22 18:38, Andrei Alexandrescu wrote:

I'm clearly outta my depth here, basing myself off of giving
http://sass-lang.com/guide a couple minutes. From what I can tell here's
how ddoc matches up sass features:

Pre-processing: yes
Variables: yes
Nesting: no
Partials, Import: somewhat (by passing several ddoc files to dmd)
Mixins: yes
Extend/Inheritance: no
Operators: no

I'm glad to see a revamp of dlang.org happening. Again if the added
dependencies carelessly and only for minor convenience.

I'm not going to argue which is best. But since I started to use Sass, I
see no reason to use plain CSS. Even just for nesting, which is the most
used feature I've seen people use, I think it's worth it. Although, I'm
using Ruby on Rails which comes bundled with Sass.

--
/Jacob Carlborg

Apr 22 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 22 April 2014 at 19:34:08 UTC, Jacob Carlborg wrote:
On 2014-04-22 18:38, Andrei Alexandrescu wrote:

I'm clearly outta my depth here, basing myself off of giving
http://sass-lang.com/guide a couple minutes. From what I can
tell here's
how ddoc matches up sass features:

Pre-processing: yes
Variables: yes
Nesting: no
Partials, Import: somewhat (by passing several ddoc files to
dmd)
Mixins: yes
Extend/Inheritance: no
Operators: no

I'm glad to see a revamp of dlang.org happening. Again if the
dependencies carelessly and only for minor convenience.

I'm not going to argue which is best. But since I started to
use Sass, I see no reason to use plain CSS. Even just for
nesting, which is the most used feature I've seen people use, I
think it's worth it. Although, I'm using Ruby on Rails which
comes bundled with Sass.

I'm no Rails (or Ruby) developer but I use Sass for all my
styling needs for a long time now. It was the only reason I had
ruby installation on my computer (nowdays I use libsass, so no
ruby.. yey).

I find it really easy to setup and use thanks to npm and
node-sass package (I prefer not to manually compile my tools),
and build tools like grunt and (now more popular) gulp really
make the life easier for front-end projects (which I still have
to do every once in a while). I just hope we will have such
ecosystem one day in D (with help of gulp).

Apr 22 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 22 April 2014 at 16:38:04 UTC, Andrei Alexandrescu
wrote:
On 4/21/14, 11:51 PM, Jacob Carlborg wrote:
On 21/04/14 23:23, Andrei Alexandrescu wrote:

dependencies at
this point. We depend on dpl-docs already, and the tool was
difficult to
install and broke from one dmd release to the next. SÃ¶nke was
nice and
proactive about it, but he's an active member of the
community. If we
find issues with tooling coming from the outside - and we
will - we're
on our own. It would help if many people in the community are
fluent
with them.

I've used Sass a lot. Although not via node.

Good to know, thanks.

Adding a tool right now that has overlapping functionality
with
ddoc/dpl-docs, and that is relatively unknown within the
community
sounds like a tall order.

Sass doesn't overlap with ddoc.

I'm clearly outta my depth here, basing myself off of giving
http://sass-lang.com/guide a couple minutes. From what I can
tell here's how ddoc matches up sass features:

Pre-processing: yes
Variables: yes
Nesting: no
Partials, Import: somewhat (by passing several ddoc files to
dmd)
Mixins: yes
Extend/Inheritance: no
Operators: no

I'm glad to see a revamp of dlang.org happening. Again if the
can't add dependencies carelessly and only for minor
convenience.

since recently. Is it helping/competing with the new tools you

Andrei

It's not competing with Sass. Sass would make it easier for me to
faster write needed styling and also more importantly to have
style files easy to maintain later (I had worked few times with
monolithic 3000+ lines long CSS files and can attest that it's
much easier to work with nice hierarchy of small SCSS files).

I can surely do without Sass and use plain CSS but to keep it
maintainable I would need to split it to multiple files and would
need a tool to concat those later to the target CSS (this can be
done with cat but it's non-standard on windows) and then I would
need a tool to minify that CSS.

These are simple tools, and they can be written from scratch in D
(which I would like to do, but then I won't be working on
redesign while those are done).

If I would use Sass, I would not only get really nice and
powerful DSL to write styles in but I would get tools to concat
and minify CSS.

As I've said in message to Dicebot I would not use npm as it
would be bad marketing, but I would really like to use libsass
(sassc - the compiler, to be precise, libsass is a library used
by sassc) which written in C.

If that's too much dependencies I'll have to go with plain CSS
files.

And I've already decided to use Make instead of gulp (a npm
packaged build tool for node.js).

The only thing that remains is JavaScript minifyer. I have tried
almost all of them, Google Closure Compiler, YUICompressor,
jsmin, UglifyJS and in my experience UgifyJS[1] is definitely the
files but you must stick to Google's rules of writing and
annotating your code, which I find too limiting).

The only problem with UglifyJS is that it's a Node.js
library/tool...
So I don't know what to do about that. Sure, there are online
versions of both Closure Compiler and UglifyJS but they cannot be
integrated in build system (well, not without requirement of
internet connection).

I wonder if DMDScript's parser could be used to write JS minifier
in D. This is actually something I would really like to look into
but there is definitely not small amount of work needed to
develop a tool like that. So it will have to wait, sadly.

So, as I'm not aware of any native good JS minifing tool I'd skip
that step for now. We can optimize that later (anyway, I'll keep
JS usage on bare minimum).

The only question yet remaining is if I can depend on sassc[2] or
not?

[1] https://github.com/mishoo/UglifyJS
[2] https://github.com/hcatlin/sassc

Apr 22 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
I wrote a css expander that has a little bit of SASS features.

Previously it was hidden in my html.d on my misc. github, but I
just now made it a standalone program in a separate repo:

Check out the demo input file

and demo result file

to get an idea of what it does.

Apr 22 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:
I wrote a css expander that has a little bit of SASS features.

Previously it was hidden in my html.d on my misc. github, but I
just now made it a standalone program in a separate repo:

Check out the demo input file

and demo result file

to get an idea of what it does.

Wow, this looks really nice! It has variables, mixins, nested
selectors and includes.. That's all I need!

Only.. any chance of making Â¤ prefix configurable via cmdline
params? :)
Ideally I would use   as prefix, but that may interfere with CSS
-rules (I see you have CssAtRule class to handle those), so I'd
use some character that's easier to type like $(but that is used for parent selector in upcoming CSS 4)...  Apr 22 2014 "Adam D. Ruppe" <destructionator gmail.com> writes: On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic wrote: Wow, this looks really nice! It has variables, mixins, nested selectors and includes.. That's all I need! Yea, I wrote this several years ago before even knowing about sass based on what annoyed me about CSS and it looks like me and the sass people had a lot of the same complaints because our results are almost compatible. I think sass does a better job with calculations but meh, I just use box-sizing: border-box and then I don't care as much about calculations anymore anyway! Ideally I would use as prefix, but that may interfere with CSS -rules (I see you have CssAtRule class to handle those), so I'd use some character that's easier to type like$ (but
that is used for parent selector in upcoming CSS 4)...

Yeah, that's why I picked the weird symbol, I wanted something
that wasn't going to be used anywhere else in normal CSS so it
wouldn't conflict. (The implementation here is stupid simple: it
just does indexOf this symbol and then replaces it. The denesting
is a more complete css parser, but the macros replacement is
plain text search.)

Anyway, I updated the github to allow $to be used.  Apr 23 2014 Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes: On 4/23/2014 9:11 AM, Adam D. Ruppe wrote: On Tuesday, 22 April 2014 at 23:45:43 UTC, Aleksandar Ruzicic wrote: Wow, this looks really nice! It has variables, mixins, nested selectors and includes.. That's all I need! Yea, I wrote this several years ago before even knowing about sass based on what annoyed me about CSS and it looks like me and the sass people had a lot of the same complaints because our results are almost compatible. I think sass does a better job with calculations but meh, I just use box-sizing: border-box and then I don't care as much about calculations anymore anyway! "box-sizing: border-box" is proof of what I've said all along: Microsoft got the box model right in old IEs, and W3C got it wrong.  Apr 23 2014 "Rikki Cattermole" <alphaglosined gmail.com> writes: On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote: I wrote a css expander that has a little bit of SASS features. Previously it was hidden in my html.d on my misc. github, but I just now made it a standalone program in a separate repo: https://github.com/adamdruppe/cssexpand Check out the demo input file https://github.com/adamdruppe/cssexpand/blob/master/demo/test.css and demo result file https://github.com/adamdruppe/cssexpand/blob/master/demo_result.css to get an idea of what it does. Any chance to get this separated out just for the css part of it? And onto the dub repository? I would really like to use this for Cmsed! And ugh can I change that weird symbol to '$'?

Apr 22 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole
wrote:
Any chance to get this separated out just for the css part of
it?

Hmm, you know, maybe that wouldn't be too hard. I thought it used
dom.d's css parser but it actually doesn't! So I could probably
write a little css module that doesn't depend on the others
(except color.d).

I might work on it tonight.

And ugh can I change that weird symbol to '$'? Use std.array.replace to change it before passing to the macro system. There's just the problem then that$ is a fairly common
symbol so it will conflict with some other stuff.

Apr 23 2014
"Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 23 April 2014 at 13:22:02 UTC, Adam D. Ruppe wrote:
On Wednesday, 23 April 2014 at 04:08:20 UTC, Rikki Cattermole
wrote:
Any chance to get this separated out just for the css part of
it?

Hmm, you know, maybe that wouldn't be too hard. I thought it
used dom.d's css parser but it actually doesn't! So I could
probably write a little css module that doesn't depend on the
others (except color.d).

I might work on it tonight.

Thanks! I will be looking forward to it on the dub repository.

And ugh can I change that weird symbol to '$'? Use std.array.replace to change it before passing to the macro system. There's just the problem then that$ is a fairly common
symbol so it will conflict with some other stuff.

Okay, doesn't look too bad of a deal that.

Apr 23 2014
"John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:
I wrote a css expander that has a little bit of SASS features.

Previously it was hidden in my html.d on my misc. github, but I
just now made it a standalone program in a separate repo:

Check out the demo input file

and demo result file

to get an idea of what it does.

This is awesome. I think I might try it out for my next web-dev
contract. If it could be put on code.dlang.org that would be
awesome.

I've always been tempted to use Sass or similar, but this seems
like the simple tool I've actually wanted.

Apr 23 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/23/2014 5:55 PM, John Colvin wrote:
On Tuesday, 22 April 2014 at 23:08:45 UTC, Adam D. Ruppe wrote:
I wrote a css expander that has a little bit of SASS features.

Previously it was hidden in my html.d on my misc. github, but I just
now made it a standalone program in a separate repo:

Check out the demo input file

and demo result file

to get an idea of what it does.

This is awesome. I think I might try it out for my next web-dev
contract. If it could be put on code.dlang.org that would be awesome.

I've always been tempted to use Sass or similar, but this seems like the
simple tool I've actually wanted.

SCSS has always been more interesting to me than SASS, but yea, this
seems to pretty much be an independently-developed equivalent to SCSS,
which is pretty cool.

Apr 23 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 April 2014 at 22:12:08 UTC, Nick Sabalausky
wrote:
SCSS has always been more interesting to me than SASS, but yea,
this seems to pretty much be an independently-developed
equivalent to SCSS, which is pretty cool.

The funny thing is I wrote this thing a few years ago, 2011 I
think, and I've been using it on several sites too. It's just
been hidden from the general public in my misc. github :P

There's also a javascript macro expander which adds foreach to
that language via text macro hidden away in that html.d as well...

Apr 23 2014
Jacob Carlborg <doob me.com> writes:
On 24/04/14 00:12, Nick Sabalausky wrote:

SCSS has always been more interesting to me than SASS, but yea, this
seems to pretty much be an independently-developed equivalent to SCSS,
which is pretty cool.

Technically, Sass is the name of the language. It provides two syntaxes,
SASS and SCSS. SCSS seems to be the preferred one. It's used as the
default for examples on the web site, Ruby on Rails uses this by
default. It's also a superset of CSS.

--
/Jacob Carlborg

Apr 23 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote:
If it could be put on code.dlang.org that would be awesome.

http://code.dlang.org/packages/cssexpand

Apr 23 2014
"Rikki Cattermole" <alphaglosined gmail.com> writes:
On Wednesday, 23 April 2014 at 23:17:02 UTC, Adam D. Ruppe wrote:
On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote:
If it could be put on code.dlang.org that would be awesome.

http://code.dlang.org/packages/cssexpand

Can we have it as a library? Instead of as only an executable?
Aka no main function.

Apr 23 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole
wrote:
Can we have it as a library?

css.d in there has the lib code now with my other html stuff
stripped out so it has fewer dependencies. Can dub just use it
without using the little main file?

Note btw that this code is *brutally* slow and should be done
ahead of time or at least aggressively cached; if you regenerate
the file on each request you'll be surprised by how much cpu time
it wastes.

The implementation is pretty much a brute force string search in
a replace loop.

Apr 24 2014
"Rikki Cattermole" <alphaglosined gmail.com> writes:
On Thursday, 24 April 2014 at 14:42:44 UTC, Adam D. Ruppe wrote:
On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole
wrote:
Can we have it as a library?

css.d in there has the lib code now with my other html stuff
stripped out so it has fewer dependencies. Can dub just use it
without using the little main file?

Ugh it can yes. But when you set the target type it definitely
cannot.

You probably want a dub.json file like this:

{
"name": "cssexpand",
"description": "A CSS expansion program",
"dependencies": {
"cssexpand:library": "~master"
},
"subPackages": [
{
"name": "tool",
"dependencies": {
"cssexpand:library": "~master"
},
"mainSourceFile": "src/cssexpand.d",
"targetType": "executable"
},
{
"name": "library",
"sourceFiles": ["src/css.d", "src/color.d"],
"targetType": "library"
}
]
}

Defaults a library. To run the tool its basically:
dub run cssexpand:tool toolargs...
Or you can swap them, up to you.

Note btw that this code is *brutally* slow and should be done
ahead of time or at least aggressively cached; if you
regenerate the file on each request you'll be surprised by how
much cpu time it wastes.

Lets not go into how much javascript code I'm generating in Cmsed
;) So not a worry.

The implementation is pretty much a brute force string search
in a replace loop.


Apr 24 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 April 2014 at 15:53:13 UTC, Rikki Cattermole
wrote:
You probably want a dub.json file like this:

I added the configurations Sonke suggested, see if it works now.

Apr 24 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 24.04.2014 16:42, schrieb Adam D. Ruppe:
On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole wrote:
Can we have it as a library?

css.d in there has the lib code now with my other html stuff stripped
out so it has fewer dependencies. Can dub just use it without using the
little main file?

This should automatically yield two configurations - "application" and
"library":

{
"name": "cssexpand",
"description": "A CSS expansion program",
"mainSourceFie":"src/cssexpand.d"
}

Running DUB directly on cssexpand will build the executable by default
and using it as a dependency will cause it to be build it as a library.

Apr 24 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 24.04.2014 17:59, schrieb SÃ¶nke Ludwig:
Am 24.04.2014 16:42, schrieb Adam D. Ruppe:
On Thursday, 24 April 2014 at 03:59:00 UTC, Rikki Cattermole wrote:
Can we have it as a library?

css.d in there has the lib code now with my other html stuff stripped
out so it has fewer dependencies. Can dub just use it without using the
little main file?

This should automatically yield two configurations - "application" and
"library":

...

Meh, unfortunately it requires to add the tow configurations manually:

{
"name": "cssexpand",
"description": "A CSS expansion program",
"mainSourceFile": "src/cssexpand.d",
"configurations": [
{
"name": "application",
"targetType": "executable"
},
{
"name": "library",
"targetType": "library",
"excludedSourceFiles": ["src/cssexpand.d"]
}
]
}

BTW, no need to keep both, dub.json and package.json. If you want to
stay compatible with old DUB versions, just use package.json, it will
still be supported for new versions as well.

Apr 24 2014
"Martin Nowak" <code dawg.eu> writes:
On Wednesday, 23 April 2014 at 23:17:02 UTC, Adam D. Ruppe wrote:
On Wednesday, 23 April 2014 at 21:55:48 UTC, John Colvin wrote:
If it could be put on code.dlang.org that would be awesome.

http://code.dlang.org/packages/cssexpand

Nice, thanks a lot. How much effort would it be to turn this into
a full SCSS compiler?
There is also a C project to draw from.
https://github.com/hcatlin/libsass

I think it would make a great addition to our D web stack.

Apr 24 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 April 2014 at 07:59:20 UTC, Martin Nowak wrote:
Nice, thanks a lot. How much effort would it be to turn this
into a full SCSS compiler?

Hmm, looking at the sass webpage, I think I could do some of the
features but prolly not all and with a different syntax. So it
wouldn't work for a full scss compiler.

If you want that, just use that C library or the ruby original.

My thingy is really just a generic text macro system with an
extension that kinda understands css syntax and simply aims to be
good enough for me. I can add to it but since it is good enough
for me already, I don't have a pressing desire to go all the way.
(As you might have heard on irc, I started a new job a couple
weeks ago tho.... and it is a Ruby on Rails thing, so who knows,
maybe I'll use the sass in that and find something I like enough
to spend the time cloning it, but so far I use sass as just a
substitute for my own cssexpand.)

Below is my impression of the sass docs.

Looks like the two big things they offer that I don't are
inheritance and math.

Inheritance might be easy, I parse it out anyway so a referencing
thingy could do that, sass calls that  extend. Math is something
I avoided because it isn't terribly useful IMO and getting the
units right isn't easy. What's 1em / 16px? Depends on the font
size... which depends on the whole dynamic cascade.

Perhaps a unit mismatch could just issue an error though,
sidestepping all that. So a little dimensional analysis!

We have some different syntax details though, like their variable
assignment vs my set macro and the parent selector referencing in
nested things is different.

Actually, the sass way of & might be a bit better than mine. For
example, in mine:

a {
:hover { color: red; }
}

expands into:

a {}
a:hover { color: red; }

If you wanted to reference a child with a pseudoclass, you'd have
to do:

a {
*:hover { color: red; }
}

then then gets you

a *:hover { ... }

Similarly, to add a class to the parent, mine does:

a {
\&.foo {
}
}

expands to a.foo {}

Something sass does that mine does NOT do is:

a {
body & {}
}

which expands into body a {} and that's potentially useful. I

* * *

I've done the import thing before but I don't think it was in
css.d, I think I did that in the work app's proprietary file.

I do support  media rules but only on the outer level. sass also
supports them inside a nested thing. That's kinda useful.

* * *

Looping and such? Yikes. I think I actually do support looping
via one of the macros, but the syntax is pretty different.

Apr 24 2014
Jacob Carlborg <doob me.com> writes:
On 2014-04-24 16:19, Adam D. Ruppe wrote:

Hmm, looking at the sass webpage, I think I could do some of the
features but prolly not all and with a different syntax. So it wouldn't
work for a full scss compiler.

Sass really has some advanced features. It's possible to create a
function in Ruby which you can call from Sass.

--
/Jacob Carlborg

Apr 24 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 24 April 2014 at 18:46:35 UTC, Jacob Carlborg wrote:
Sass really has some advanced features. It's possible to create
a function in Ruby which you can call from Sass.

Yeah, going that far definitely isn't feasible. But I don't think
there's a need for that either.

and besides you can always add a macro function to my thing in D
too (that's how the color things work anyway)

Apr 24 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/22/2014 5:47 PM, Aleksandar Ruzicic wrote:
and would need a
tool to concat those later to the target CSS (this can be done with cat
but it's non-standard on windows)

FWIW, on windows:

type input1.txt > output.txt
type input2.txt >> output.txt
type input3.txt >> output.txt

Apr 22 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 21 April 2014 at 15:48:45 UTC, Aleksandar Ruzicic
wrote:
On Sunday, 20 April 2014 at 17:11:22 UTC, Andrei Alexandrescu
wrote:
On 4/19/14, 1:02 AM, Aleksandar Ruzicic wrote:
I'm planning to start working on this as soon as I get
approval
from Walter/Andrei, and as most of people who answered here
are agreed
that redesign would be a good thing I hope they wouldn't
oppose..

Let's do it. Thank you very much! -- Andrei

Just one question, would it be okay to depend on node.js/npm to
manage dependencies (i.e. CSS/JS frameworks) and build CSS/JS
files?

As I'd use Sass for styling, which must be translated to CSS
(I'd use node-sass package witch doesn't require ruby), and
browserify to have Common-JS modules..

I think it is very important to dogfood here and add any
currently missing dependencies as dub packages instead.

Apr 21 2014
Jacob Carlborg <doob me.com> writes:
On 21/04/14 23:33, Dicebot wrote:

I think it is very important to dogfood here and add any currently
missing dependencies as dub packages instead.

Unless we can use libsass, I would say it's not very productive to
implement a new Sass compiler, just to avoid a dependency.

--
/Jacob Carlborg

Apr 21 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:
Unless we can use libsass, I would say it's not very productive
to implement a new Sass compiler, just to avoid a dependency.

I never use css macros-tools, regular template libraries are
usually better (e.g. jinja2 allows me to execute python
expressions if needed). With current browsers the CSS is getting
much more streamlined too and the worst browser bugs require
javascript detection anyway so macros don't cut it.

If you use static fallbacks then dynamic CSS calc() expressions
are starting to become useful (lacking on Safari 5 and some
Android browsers).

For javascript I strongly suggest using the very efficient and
typesafe Closure compiler. It has a  good optimizer, dead code
elimination and tight minimization. And it requires no
install-dependencies since it is available as a REST web service:

http://closure-compiler.appspot.com/home

Closure type annotations are in comments, so the annotated
javascript code runs as regular javascript.

Ola.

Apr 22 2014
Jacob Carlborg <doob me.com> writes:
On 2014-04-22 09:56, "Ola Fosheim GrÃ¸stad"

I never use css macros-tools, regular template libraries are usually
better (e.g. jinja2 allows me to execute python expressions if needed).
With current browsers the CSS is getting much more streamlined too and
the worst browser bugs require javascript detection anyway so macros
don't cut it.

I usually use these languages together with Ruby on Rails. With the
assets pipeline in RoR it's possible to pipe several pre-processors
together. Erb (Embedded Ruby) -> Sass -> CSS.

--
/Jacob Carlborg

Apr 22 2014
"Dicebot" <public dicebot.lv> writes:
On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:
On 21/04/14 23:33, Dicebot wrote:

I think it is very important to dogfood here and add any
currently
missing dependencies as dub packages instead.

Unless we can use libsass, I would say it's not very productive
to implement a new Sass compiler, just to avoid a dependency.

I think using libsass is superior to using node/npm based
dependency. Using pretty much anything from node.js
infrastructure will be a big marketing hit for vibe.d (being its
direct competitor in D world).

Apr 22 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 22 April 2014 at 12:27:23 UTC, Dicebot wrote:
On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg wrote:
On 21/04/14 23:33, Dicebot wrote:

I think it is very important to dogfood here and add any
currently
missing dependencies as dub packages instead.

Unless we can use libsass, I would say it's not very
productive to implement a new Sass compiler, just to avoid a
dependency.

I think using libsass is superior to using node/npm based
dependency. Using pretty much anything from node.js
infrastructure will be a big marketing hit for vibe.d (being
its direct competitor in D world).

I see what you mean. I get that it wouldn't be good marketing so
I decided not to use npm.

Although I would really like if we could do dub install -g
<package> to distribute tools, like you can with npm..

Apr 22 2014
"Dicebot" <public dicebot.lv> writes:
On Tuesday, 22 April 2014 at 21:21:13 UTC, Aleksandar Ruzicic
wrote:
On Tuesday, 22 April 2014 at 12:27:23 UTC, Dicebot wrote:
On Tuesday, 22 April 2014 at 06:53:41 UTC, Jacob Carlborg
wrote:
On 21/04/14 23:33, Dicebot wrote:

I think it is very important to dogfood here and add any
currently
missing dependencies as dub packages instead.

Unless we can use libsass, I would say it's not very
productive to implement a new Sass compiler, just to avoid a
dependency.

I think using libsass is superior to using node/npm based
dependency. Using pretty much anything from node.js
infrastructure will be a big marketing hit for vibe.d (being
its direct competitor in D world).

I see what you mean. I get that it wouldn't be good marketing
so I decided not to use npm.

Although I would really like if we could do dub install -g
<package> to distribute tools, like you can with npm..

You can do dub fetch package; dub run package AFAIR for
packages that are applications. Though it does not make any sense
to add something that is not a D  project to dub, such a popular
thing as sass compiler must have own package, whatever distro
dlang web server runs on.

Apr 23 2014
Martin Nowak <code dawg.eu> writes:
On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:
Just one question, would it be okay to depend on node.js/npm to manage
dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

As I'd use Sass for styling, which must be translated to CSS (I'd use
node-sass package witch doesn't require ruby), and browserify to have
Common-JS modules..

Why do you want to write the whole CSS yourself? Isn't something like
bootstrap more appropriate for the task?

Apr 22 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/22/2014 6:26 PM, Martin Nowak wrote:
On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:
Just one question, would it be okay to depend on node.js/npm to manage
dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

As I'd use Sass for styling, which must be translated to CSS (I'd use
node-sass package witch doesn't require ruby), and browserify to have
Common-JS modules..

Why do you want to write the whole CSS yourself? Isn't something like
bootstrap more appropriate for the task?

Apparently they can't even manage make basic links work properly:

http://getbootstrap.com/examples/starter-template/

How anyone can manage to fuck up <a href="...">...</a> is beyond me.

Apr 22 2014
Jacob Carlborg <doob me.com> writes:
On 23/04/14 00:57, Nick Sabalausky wrote:

Apparently they can't even manage make basic links work properly:

http://getbootstrap.com/examples/starter-template/

How anyone can manage to fuck up <a href="...">...</a> is beyond me.

What's fucked up with the links?

--
/Jacob Carlborg

Apr 22 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/23/2014 2:34 AM, Jacob Carlborg wrote:
On 23/04/14 00:57, Nick Sabalausky wrote:

Apparently they can't even manage make basic links work properly:

http://getbootstrap.com/examples/starter-template/

How anyone can manage to fuck up <a href="...">...</a> is beyond me.

What's fucked up with the links?

They don't work.

But...maybe they're only intended to be single-page-only examples? (Now

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

But I have noticed a lot of the sites that use anchor links to switch to
completely different pages are basically broken. Since the very
*beginning* of HTML, links have always been downright trivial to
implement, and have always been considerably *easier* to *not* require
JS. It's pretty much the single simplest, easiest, most fundamental
thing in HTML. And yet, more than a decade now after <a onclick="...">
linking inexplicably appeared, some people are *still* trying to
implement links using JS. It's insane.

However, you'll have to pardon that little rant. When I posted that
"Apparently they can't even manage make basic links work properly", I
swear it wasn't my intention to do another JS-rant. Coming from me, JS
rants are pretty much redundant at this point ;)

Apr 23 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Wed, Apr 23, 2014 at 06:08:52PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
[...]
But I have noticed a lot of the sites that use anchor links to switch
to completely different pages are basically broken. Since the very
*beginning* of HTML, links have always been downright trivial to
implement, and have always been considerably *easier* to *not* require
JS. It's pretty much the single simplest, easiest, most fundamental
thing in HTML. And yet, more than a decade now after <a onclick="...">
linking inexplicably appeared, some people are *still* trying to
implement links using JS. It's insane.

[...]

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
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
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
(Argh! Accidentally emailed this to digitalmars-d puremagic.com twice!
Actually posting to NG now...)

On 4/23/2014 6:48 PM, H. S. Teoh via Digitalmars-d wrote:
until sometime in the last few
years I got so sick of JS eating up CPU, memory, causing needless
browser slowdowns, popping up unwanted ads and nag dialogs, that now I'm
back to JS being off by default, and only (grudgingly) enabled for a
handful of specific sites that actually *need* it. It's amazing how much
faster the web suddenly became, overnight.

That's why I do it! That plus the lack of modal CSS pop-in windows.
(Seriously, no sooner do the browsers finally kill off popups, but then
overzealous designers go replacing them with *modal* versions! And these
new ones break basic browser functionality even *more*.)

The *truly* amazing thing is that many of those slow-with-JS sites are
using JS/AJAX specifically *because* they actually believe it makes
their site faster (I bet many of them are probably running on Node.js or
PHP, too). Always, of course, based on the same half-baked,
never-tested, but oft-repeated theory that reducing a few fractions of a
kilobyte by doing partial page-reloads actually makes the web noticeably
faster (yea right).

Shit, even in the days before 14.4 modems, let alone 56k or broadband,
transferring the actual HTML was practically nothing, it was the
occasional use of an image or two that slowed things down - *because
those take a heck of a lot more bytes than HTML*. Even today, one
gravitar image, one "share on site x" logo, or one stock photo of a
model pretending to be an overjoyed IT worker, and *all* the
partial-HTML savings are completely blown several times over. Not to
mention all the extra CSS/HTML/JS used for rigging up a

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 ;) ]

Another new fad nowadays seems to be CSS popups that need JS to make
them go away. My usual reaction to that is to close the tab and move on.
Or, if I'm feeling particularly tolerant that day, switch to user
stylesheet mode (i.e., completely disregard the site's CSS and use my
own), and just scour the raw text for the real content

I love this FF extension:

If I can't get rid of the garbage with that, the site's not worth
spending another second on. I won't be bothered to even *think* about
some poorly-made site's CSS, let alone touch any custom stylesheets.

(which usually
occupies, oh, 20% of the total text on the page -- apparently nowadays
minimizing your S/N ratio is in, providing useful content is out).

Yup. Makes me miss "markup".

But then I go back to my own site, type <b></b> instead of <span
class="something-that-implicitly-says-font-weight-bold-in-the-css"></span>,
and all is well. Bonus points for me whenever <b> offends anyone's sense
of "proper" HTML. :)

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

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

other places where I can get similar information! >:-)

Yea that's a big thing, too. So many designers actually believing their
site is so special that people won't just move on or that being
hitech-elitist won't hurt their site.

JS rants are fun. ;-)

Heh, yea, it's an addiction :)

Apr 24 2014
Jacob Carlborg <doob me.com> writes:
On 24/04/14 00:08, Nick Sabalausky wrote:

They don't work.

But...maybe they're only intended to be single-page-only examples? (Now

it to.

If so, then I must have misunderstood the examples. The fact that
they're all pointing to different anchor links threw me off and made me
assume they were supposed to be functional. (I'm accustomed to blank
zero-length anchors being used to indicate "intentionally non-functional

Yeah, I don't know why they do that.

But I have noticed a lot of the sites that use anchor links to switch to
completely different pages are basically broken. Since the very
*beginning* of HTML, links have always been downright trivial to
implement, and have always been considerably *easier* to *not* require
JS. It's pretty much the single simplest, easiest, most fundamental
thing in HTML. And yet, more than a decade now after <a onclick="...">
linking inexplicably appeared, some people are *still* trying to
implement links using JS. It's insane.

I hate that as well. Sometimes I come to a page, with JS disabled, and
it's completely blank. Then my thought process goes something like this:
"Hmm, is it loaded. Yes, strange. Oh right I've disabled JavaScript.
What is this pieces of crap, can't they design a web site without JS".

However, you'll have to pardon that little rant. When I posted that
"Apparently they can't even manage make basic links work properly", I
swear it wasn't my intention to do another JS-rant. Coming from me, JS
rants are pretty much redundant at this point ;)

No worries :)

--
/Jacob Carlborg

Apr 23 2014
"Martin Nowak" <code dawg.eu> writes:
 http://getbootstrap.com/examples/starter-template/

How anyone can manage to fuck up <a href="...">...</a> is
beyond me.

Nick what are you talking about? They referenced some anchors in
their example page and that works.

Apr 22 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 22 April 2014 at 22:26:39 UTC, Martin Nowak wrote:
On 04/21/2014 05:48 PM, Aleksandar Ruzicic wrote:
Just one question, would it be okay to depend on node.js/npm
to manage
dependencies (i.e. CSS/JS frameworks) and build CSS/JS files?

As I'd use Sass for styling, which must be translated to CSS
(I'd use
node-sass package witch doesn't require ruby), and browserify
to have
Common-JS modules..

Why do you want to write the whole CSS yourself? Isn't
something like bootstrap more appropriate for the task?

I would use Foundation[1] instead of Bootstrap.

[1] http://foundation.zurb.com/

Apr 22 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/22/2014 7:29 PM, Aleksandar Ruzicic wrote:
On Tuesday, 22 April 2014 at 22:26:39 UTC, Martin Nowak wrote:
Why do you want to write the whole CSS yourself? Isn't something like
bootstrap more appropriate for the task?

I would use Foundation[1] instead of Bootstrap.

[1] http://foundation.zurb.com/

Eww. Font size and image scaling should *not* be a function of window
size. That's just...yuck. Let the system determine it's own appropriate
base font size.

And it's all in that horrible, ugly, "giant sized, yet minimal content
and maximal blank space" style that's so inexplicably popular with the
latest batches of web startups.

*shudder*

Apr 22 2014
"Martin Nowak" <code dawg.eu> writes:
 Eww. Font size and image scaling should *not* be a function of
window size. That's just...yuck. Let the system determine it's
own appropriate base font size.

And it's all in that horrible, ugly, "giant sized, yet minimal
content and maximal blank space" style that's so inexplicably
popular with the latest batches of web startups.

*shudder*

Yeah, let's have a page like Peter Norvig (http://norvig.com).
It's all about the content after all and if that is good the rest
doesn't matter.

Apr 22 2014
"Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 23 April 2014 at 06:47:58 UTC, Martin Nowak wrote:
Yeah, let's have a page like Peter Norvig (http://norvig.com).
It's all about the content after all and if that is good the
rest doesn't matter.

There's a middle ground here.

Apr 23 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/23/2014 2:47 AM, Martin Nowak wrote:
Eww. Font size and image scaling should *not* be a function of window
size. That's just...yuck. Let the system determine it's own
appropriate base font size.

And it's all in that horrible, ugly, "giant sized, yet minimal content
and maximal blank space" style that's so inexplicably popular with the
latest batches of web startups.

*shudder*

Yeah, let's have a page like Peter Norvig (http://norvig.com). It's all
about the content after all and if that is good the rest doesn't matter.

I didn't say style was irrelevent. I only said that there should
actually *be* content.

Apr 23 2014
"Martin Nowak" <code dawg.eu> writes:
 Yeah, let's have a page like Peter Norvig (http://norvig.com).
It's all
about the content after all and if that is good the rest
doesn't matter.

I didn't say style was irrelevent. I only said that there
should actually *be* content.

Sorry for the irony :), indeed fluffy sites without content are
useless.
Reminds me of http://vimeo.com/89527215.

Apr 23 2014
"Martin Nowak" <code dawg.eu> writes:
 I would use Foundation[1] instead of Bootstrap.

[1] http://foundation.zurb.com/

Whatever gets the job done. I haven't yet worked with Foundation,
but it looks reasonable. Maybe we can limit the SCSS dependency
by checking in the rendered CSS, so only people working on the
style would need a sass compiler.
One remark though, try to stay away from heavy client-side JS,
dlang.org is mostly a static website and anything that makes you
wait 5s for the site to be rendered misses the point.

Apr 23 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Wednesday, 23 April 2014 at 07:02:50 UTC, Martin Nowak wrote:
I would use Foundation[1] instead of Bootstrap.

[1] http://foundation.zurb.com/

Whatever gets the job done. I haven't yet worked with
Foundation, but it looks reasonable. Maybe we can limit the
SCSS dependency by checking in the rendered CSS, so only people
working on the style would need a sass compiler.
One remark though, try to stay away from heavy client-side JS,
dlang.org is mostly a static website and anything that makes
you wait 5s for the site to be rendered misses the point.

I was thinking of that too, but I used this approach on one of
previous projects (both, SCSS and generated CSS files were under
git) and it just gave me headache as the coworker was changing
CSS and committing those changes which leaved SCSS and CSS files
out of sync. But we could easily just agree not to do it, and
state that we don't accept pull requests that have direct changes
in CSS.

Apr 23 2014
"Martin Nowak" <code dawg.eu> writes:
 Maybe we can limit the SCSS dependency by checking in the
rendered CSS, so only people working on the style would need a
sass compiler.

I was thinking of that too, but I used this approach on one of
previous projects (both, SCSS and generated CSS files were
under git) and it just gave me headache as the coworker was
changing CSS and committing those changes which leaved SCSS and
CSS files out of sync.

Obviously not the way to do it.

But we could easily just agree not to do it, and state that we
don't accept pull requests that have direct changes in CSS.

I think this will work out nice, css doesn't change very often.

Apr 23 2014
"Kapps" <opantm2+spam gmail.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
-- Aleksandar

I do agree that the design of the current site is rather dated. I
rather like your new proposed design as well. One thing that
could be nicer is the search bar being a button to click. It's
standard now to just make it an input of type search with
place-holder text now, which is faster and more useable. Even
better, it could be automatically focused on when you load the
(documentation) page so you can immediately start typing to look
up an API / language feature.

People who go directly to the homepage are likely coming to check
out what D is or why they should use it (which the homepage
upon), or search the documentation (which is still a few clicks
away). I'd argue that most people are going for the third option
it out don't return frequently to check it out again. Having an
immediate search field, ideally with autofocus, makes finding

rather than the top nav-bar would be an improvement as well.
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
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
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Saturday, 19 April 2014 at 00:08:06 UTC, Kapps wrote:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
So, what do you guys think?
-- Aleksandar

I do agree that the design of the current site is rather dated.
I rather like your new proposed design as well. One thing that
could be nicer is the search bar being a button to click. It's
standard now to just make it an input of type search with
place-holder text now, which is faster and more useable. Even
better, it could be automatically focused on when you load the
(documentation) page so you can immediately start typing to
look up an API / language feature.

It sure looks like a button and it wouldn't be a button. It would
be a regular text (search) input field (something that would be
apparent as soon as you hover it and get that I-beam cursor over
it) that would expand on click/focus (no JS needed there, don't
worry Nick!).

People who go directly to the homepage are likely coming to
check out what D is or why they should use it (which the
improved upon), or search the documentation (which is still a
few clicks away). I'd argue that most people are going for the
just checking it out don't return frequently to check it out
again. Having an immediate search field, ideally with
autofocus, makes finding documentation a very easy task.

I'm slightly against autofocus on search field, as I am one of
people who use Backspace to navigate to previous page and I'm
always frustrated when I hit Backspace on Google search results
page and it's not taking me to previous page.
But if majority thinks that autofocus on search is a good thing
(I also think that not many people use Backspace as a means of
navigation) than I would make it like that (and if there would be
that little preferences page/popup this option is something that
can go there together with justification settings).

page rather than the top nav-bar would be an improvement as
this, for good reason. It's one of the first things that should
jump out at you when you view the site, making it as little
installer (see Dart, Python, Rust, Go, Ruby, etc). The longer /
more effort it takes to do something, the less likely people
are to try it unless they're already very convinced it's
something they need.

Download sites do that, so does sites that sell software. I think
that dlang.org should focus on promoting D as a language, and
compiler implementations should not be in spotlight.
Also I think that having Download in top-nav as a first option is
prominent enough. I've put what I think are the most important
sections in top-nav bar (other navigation items should go to
context-sensitive sidebar).

Apr 19 2014
"Rikki Cattermole" <alphaglosined gmail.com> writes:
On Saturday, 19 April 2014 at 08:16:20 UTC, Aleksandar Ruzicic
wrote:
...
think that dlang.org should focus on promoting D as a language,
and compiler implementations should not be in spotlight.
Also I think that having Download in top-nav as a first option
is prominent enough. I've put what I think are the most
important sections in top-nav bar (other navigation items
should go to context-sensitive sidebar).

Also can we have things like a getting started guide? That really
impeded me at least when I was starting out.

Apr 19 2014
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 4/19/2014 4:16 AM, Aleksandar Ruzicic wrote:
I'm slightly against autofocus on search field, as I am one of people
who use Backspace to navigate to previous page and I'm always frustrated
when I hit Backspace on Google search results page and it's not taking
me to previous page.
But if majority thinks that autofocus on search is a good thing (I also
think that not many people use Backspace as a means of navigation) than
I would make it like that (and if there would be that little preferences
page/popup this option is something that can go there together with
justification settings).

I use a browser extension to disable backspace navigation since I get
annoyed when I try to type something and the browser decides to navigate
to a different page ;).

That said, I don't really have an preference on autofocus vs not-autofocus.

Download sites do that, so does sites that sell software. I think that
dlang.org should focus on promoting D as a language, and compiler
implementations should not be in spotlight.
Also I think that having Download in top-nav as a first option is
prominent enough. I've put what I think are the most important sections
in top-nav bar (other navigation items should go to context-sensitive
sidebar).

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
it and try it, so it's good to match people's expectations here.

Apr 19 2014
"Kagamin" <spam here.lot> writes:
On Saturday, 19 April 2014 at 00:08:06 UTC, Kapps wrote:
I do agree that the design of the current site is rather dated.
I rather like your new proposed design as well. One thing that
could be nicer is the search bar being a button to click. It's
standard now to just make it an input of type search with
place-holder text now, which is faster and more useable. Even
better, it could be automatically focused on when you load the
(documentation) page so you can immediately start typing to
look up an API / language feature.

you were previously, you end up focused on search box, which is
really annoying. It also breaks page navigation (similar mistake:
floating top panel on dart site). Whether it's standard or not, I
don't know, because when I see such disgusting UX, I leave the
site and never return if possible.
What you are talking about is what opensearch is for: you type
request right in the browser without opening any site and get
straight to the search results. I personally don't use search on
the site and forcing it on me on every page transition would be
undesirable.

Apr 21 2014
"Lars T. Kyllingstad" <public kyllingen.net> writes:
On Monday, 21 April 2014 at 11:42:54 UTC, Kagamin wrote:
you were previously, you end up focused on search box, which is
really annoying. It also breaks page navigation (similar
mistake: floating top panel on dart site). Whether it's
standard or not, I don't know, because when I see such
disgusting UX, I leave the site and never return if possible.

I hate that too.  It also breaks in-page search with "/", which I
use a lot.

In fact, I get seriously annoyed whenever a web site does
*anything* to make my browser behave in an unexpected,
non-standard way.  Like those sites that hijack the arrow keys
for navigation between images or blog posts.  Or GitHub's
keyboard shortcuts.  Grrrr...

When I want that stuff, I use a browser plug-in like Vimperator
or Vimium.  I shouldn't have to install an add-on to *disable* it.

Apr 21 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Monday, 21 April 2014 at 13:14:12 UTC, Lars T. Kyllingstad
wrote:
On Monday, 21 April 2014 at 11:42:54 UTC, Kagamin wrote:
where you were previously, you end up focused on search box,
which is really annoying. It also breaks page navigation
(similar mistake: floating top panel on dart site). Whether
it's standard or not, I don't know, because when I see such
disgusting UX, I leave the site and never return if possible.

I hate that too.  It also breaks in-page search with "/", which
I use a lot.

In fact, I get seriously annoyed whenever a web site does
*anything* to make my browser behave in an unexpected,
non-standard way.  Like those sites that hijack the arrow keys
for navigation between images or blog posts.  Or GitHub's
keyboard shortcuts.  Grrrr...

When I want that stuff, I use a browser plug-in like Vimperator
or Vimium.  I shouldn't have to install an add-on to *disable*
it.

Agreed. But given that I'll be implementing "preferences page"
where you can choose your UX settings there can be autofocus
on/off option too (which I would gladly disable by default).

Apr 21 2014
"Martin Nowak" <code dawg.eu> writes:
Different strokes for different folks.
https://github.com/rejectedsoftware/ddox/pull/49

Apr 25 2014
"w0rp" <devw0rp gmail.com> writes:
I like your design. Go forth and make it happen.

On line length, the optimal line length is somewhere between 70
and 110 characters from what I have read. I found one study here
which didn't turn up a great observable difference in reading
speed or comprehension going from 80 to 110 characters.

http://www.perceptionweb.com/ecvp/ecvp03.pdf (Page 107)

This is a general theme from studies I have seen. Results seem to
vary a bit. Something inside that range appears to be good.

I recommend Bootstrap for building sites, as it was worked well
at my company. The designer here is a big fan of it, and when a
site framework makes him happy, it's got to be pretty good.

As for avoiding the SCSS dependency, I'd say just go for plain
CSS. SCSS and other CSS wrapper languages give you some nice
features, like templates for cross-browser support or variables,
but I don't think they justify the complexity involved in using
them. We've been using SCSS at the company I currently work in,
and so far all I've gotten out of SCSS is that it takes me longer
to go through the feedback loop of making a change to a CSS file
and seeing it happen in the browser, due to the milliseconds it
takes to compile the CSS file. It's really not worth the trouble.

I'll say it again because it's important, go ahead and implement
a new design right away. I look forward to it. Press on with
something to avoid a design by committee scenario from emerging.

Apr 22 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 22 April 2014 at 12:21:57 UTC, w0rp wrote:
and 110 characters from what I have read. I found one study
here which didn't turn up a great observable difference in
reading speed or comprehension going from 80 to 110 characters.

You can do all the quantitative laboratory experiments in the
world, but at the end of the day the only thing that is certain
is that people don't approach a web page as if they are
participating in a reading contest, and that people are
different, have different skills and motivation. So, being able
to adapt the page to your own needs is the "right" thing to do.

What is certain is that testing with a heterogeneous group of
real people is much more efficient than evaluation by a usability
expert, no matter how proficient that expert is. ;-)

Apr 22 2014
Jacob Carlborg <doob me.com> writes:
On 2014-04-22 14:21, w0rp wrote:
I like your design. Go forth and make it happen.

On line length, the optimal line length is somewhere between 70 and 110
characters from what I have read. I found one study here which didn't
turn up a great observable difference in reading speed or comprehension
going from 80 to 110 characters.

http://www.perceptionweb.com/ecvp/ecvp03.pdf (Page 107)

This is a general theme from studies I have seen. Results seem to vary a
bit. Something inside that range appears to be good.

I recommend Bootstrap for building sites, as it was worked well at my
company. The designer here is a big fan of it, and when a site framework
makes him happy, it's got to be pretty good.

As for avoiding the SCSS dependency, I'd say just go for plain CSS. SCSS
and other CSS wrapper languages give you some nice features, like
templates for cross-browser support or variables, but I don't think they
justify the complexity involved in using them. We've been using SCSS at
the company I currently work in, and so far all I've gotten out of SCSS
is that it takes me longer to go through the feedback loop of making a
change to a CSS file and seeing it happen in the browser, due to the
milliseconds it takes to compile the CSS file. It's really not worth the
trouble.

I say it's the opposite. I never use plain CSS or JavaScript these days.
I mostly use Ruby on Rails where this is built-in and has good support.
I'm using LiveReload together with Guard. When the Sass/CSS is updated
it doesn't even need to reload the whole page, it just updates the
stylesheet.

--
/Jacob Carlborg

Apr 22 2014
Martin Nowak <code dawg.eu> writes:
 I have also tried to design something myself (although I'm not a
designer) and this is what I came up with:

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

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

This looks great, finally something that doesn't scare off people.
Please let me know if you need any help to make this happen.

Apr 22 2014
"Aleksandar Ruzicic" <aleksandar ruzicic.info> writes:
On Tuesday, 22 April 2014 at 22:24:25 UTC, Martin Nowak wrote:
I have also tried to design something myself (although I'm not
a
designer) and this is what I came up with:

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

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

This looks great, finally something that doesn't scare off
people.
Please let me know if you need any help to make this happen.

Thanks! I'll be pushing all my work to GitHub from day one (I'll
create new branch at https://github.com/raleksandar/dlang.org) so
anyone can fork and contribute, later this would be hopefuly
merged with official dlang.org repo.

Apr 22 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 04:58:06AM -0400, Nick Sabalausky via Digitalmars-d
wrote:
On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:

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

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

[...]

I've never left terminal-only email clients. :P

For a short time at work I put up with webmail, because they didn't tell
me pop3 access was available. Boy, that was painful. Then one day I
discovered that I can use pop3, and oh the joy! I installed mutt and
fetchmail, and from that day on never looked back.

Nowadays, it seems that HTML-only mails are getting more common, which
is unfortunate. Luckily, there's elinks -dump, which one of these days
I'm gonna hook up to my .procmailrc so that I won't ever see HTML mails,
ever again. >:-)

On Thu, Apr 24, 2014 at 12:27:09PM +0000, via Digitalmars-d wrote:
On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky wrote:
I agree. Unfortunately though, browsers haven't always has reasonable
defaults, so people had to work around, so now it's all pretty much
screwed.

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

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

Funny. I find anything below 16pt unreadably small. But then again, I
have a 1600x1200 screen. :P  Which I run ratpoison on, which means every
window is maximized. So my terminals use an 18pt font to get close to an
80-column display. :P

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

TBH, I find this "pixel perfect" obsession to be really silly.  It shows
that web developers don't understand that what the user sees is NOT what
developers see, because browsers come in many sizes and shapes, and
users' screens also come in many sizes and shapes. "This site is best
viewable in AAAxYYY resolution" is so last century. When are we gonna
grow out of that?!

On Thu, Apr 24, 2014 at 01:57:32PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
Another thing that kills me about the new "big picture up top,
scroll to gigantic say-nothing text below" fad....

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

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

<a href="this-makes-me-angry-because-it-sux">Hatred.</a>

Yeah I noticed that about recent new sites. But then again, it's more
tolerable than the old "jampack every possible marketing slogan you can
onto a presumed 640x480 browser window until it's unreadably cluttered"
approach, which *still* conveyed basically no information.

"Feature-rich" has become one of those meaningless buzzwords that really

http://www.dack.com/web/bullshit.html

:-P  Along with "innovative", "comprehensive", "powerful", "creative",
"cloud", "mature", etc., all of which have lost their meaning from
marketing overuse.

T

--
The diminished 7th chord is the most flexible and fear-instilling chord.
Use it often, use it unsparingly, to subdue your listeners into
submission!

Apr 24 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 24 April 2014 at 14:59:36 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Thu, Apr 24, 2014 at 04:58:06AM -0400, Nick Sabalausky via
Digitalmars-d wrote:
On 4/23/2014 6:19 PM, H. S. Teoh via Digitalmars-d wrote:

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

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

[...]

I've never left terminal-only email clients. :P

For a short time at work I put up with webmail, because they
didn't tell
me pop3 access was available. Boy, that was painful. Then one
day I
discovered that I can use pop3, and oh the joy! I installed
mutt and
fetchmail, and from that day on never looked back.

Nowadays, it seems that HTML-only mails are getting more
common, which
is unfortunate. Luckily, there's elinks -dump, which one of
these days
I'm gonna hook up to my .procmailrc so that I won't ever see
HTML mails,
ever again. >:-)

On Thu, Apr 24, 2014 at 12:27:09PM +0000, via Digitalmars-d
wrote:
On Thursday, 24 April 2014 at 08:58:13 UTC, Nick Sabalausky
wrote:
I agree. Unfortunately though, browsers haven't always has
reasonable
defaults, so people had to work around, so now it's all
pretty much
screwed.

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

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

Funny. I find anything below 16pt unreadably small.

According to the CCS 2.1 standard 1 px == 0.75pt.

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

Thus:

16pt => 12px => 3.1mm at a reading distance of 71 cm.

Yep, that pretty tiny. :-)

TBH, I find this "pixel perfect" obsession to be really silly.
It shows that web developers don't understand that what the user
sees is NOT what developers see

If we are talking about fixed sizes, sure. Pixel perfect in this
context means that black lines of the fonts are aligned with the
pixel layout so you get sharp black lines and not blurry gray
shit that looks like it are out of focus. To get that right you
have to adjust the font/rendering engine so the lines match up.

When it comes to graphics there is no longer an excuse for not
gong whole sale SVG. IE8 is thankfully not a contender anymore!
:-) Misaligned vector-graphics is not so bad if you avoid 1
hardware-pixel thin lines. (Or you can adjust it with javascript).

One property missing on LCDs that CRTs have is the lowpass filter
after the D/A conversion, which leads to jagged artifacts. Thus
they are "pixel perfect" by nature. There is now way around it.
If you don't want "pixel perfect" then you have to go back to
CRTs where the phosphors is your reconstruction filter. Of
course, this doesn't matter with very high resolution displays.

(I am also clinging onto my 1600x1200 displayâ€¦)

"This site is best
viewable in AAAxYYY resolution" is so last century. When are we
gonna grow out of that?!

I dunno.

The current fad is: Â«this site is best viewed on a cellphone so
we have almost no content, but let's

SCALE UP THE
FONT AND
CENTER THE TEXT

so it looks nice on desktops. Mobile first!Â»

Apr 24 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 24.04.2014 17:34, schrieb "Ola Fosheim GrÃ¸stad"
According to the CCS 2.1 standard 1 px == 0.75pt.

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

Thus:

16pt => 12px => 3.1mm at a reading distance of 71 cm.

16pt => 21.3px

Apr 24 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 24 April 2014 at 15:55:36 UTC, SÃ¶nke Ludwig wrote:
Am 24.04.2014 17:34, schrieb "Ola Fosheim GrÃ¸stad"
According to the CCS 2.1 standard 1 px == 0.75pt.

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

Thus:

16pt => 12px => 3.1mm at a reading distance of 71 cm.

16pt => 21.3px

Yeah, I thought it was a bit odd, it sounded more like 9pt. I
guess Theo should look into the DPI settings if possible.

Apr 24 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Apr 24, 2014 at 03:59:17PM +0000, via Digitalmars-d wrote:
On Thursday, 24 April 2014 at 15:55:36 UTC, Sönke Ludwig wrote:
Am 24.04.2014 17:34, schrieb "Ola Fosheim Grøstad"
According to the CCS 2.1 standard 1 px == 0.75pt.

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

Thus:

16pt => 12px => 3.1mm at a reading distance of 71 cm.

16pt => 21.3px

Yeah, I thought it was a bit odd, it sounded more like 9pt. I guess Theo
should look into the DPI settings if possible.

I like my fonts nice and big. It's just me. :)

I think I got confused and misread 12px as 12pt. 12px isn't unreadably
small on a lower resolution screen: at work, where the screen resolution
is 1280x1024, I have my fonts set to 15pt, which is about 12px. At home,
with a 1600x1200 screen, I have my font set to 18pt, not sure exactly
what that is in px, but should be around 17px I think.

T

--
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

Apr 24 2014
Is this still happening? Is there a repo or a place I can go to
help?

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

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

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

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

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

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

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

So, what do you guys think?

-- Aleksandar

Any updates? Any help needed pushing this forward?

May 29 2014
"w0rp" <devw0rp gmail.com> writes:
After watching Andrei's keynote where he was asking for help, and
noticing that there wasn't any proof of someone working on this,
I took charge.

http://w0rp.com:8010/

That's the design in the form of a single page website running on
my Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I would like to keep going with this and just redesign the whole
website. A few points worth noting.

* This is entirely a vibe.d website. (See the source.)
* For pages, DDoc is replaced with diet templates.
* I would still use ddox for generating library documentation.
* The page is mostly held together with Bootstrap, which is very
good.
* The page is most of the way to being responsive (design sense),
as it should be.
* The module in the middle is missing, I'd use some future
version of Nowak's drepl and put a REPL right there on the front
page.
* The logo is something I quickly put together with InkScape.
Look at it as "please insert better logo here."

I encourage the use of diet over DDoc because it is simpler to
insert dynamic content in the page, especially so for vibe.d. The
support for doing conditional things or loops based on any
dynamic content we can think of is right there in vibe.d.

Now unfortunately, I have two major complaints, for vibe.d and D
itself.

For vibe.d, I can't think of a way to make changes to diet
templates without recompiling the whole site. This doesn't seem
so bad, given that compilation speed is very fast, but it builds
up. This is because the process of experimenting with HTML
becomes.

1. Make a change.
2. Recompile the whole program in a matter of seconds.
3. Refresh the browser window.

Those seconds in between making a change and seeing the results
really build up over time. It's probably hard to describe without
trying it yourself, but trust me, it matters. This is the kind of
thing I have recently fought against at work, and it was well
worth it. I replaced a Compass filesystem monitor with an even
slightly broken libsass CPython compiler which compiled SCSS
based on modification times. The couple seconds of difference has
definitely improved the day-to-day life of myself and the web
designer I work with.

This could be avoided if there was perhaps a way to rebuild diet
templates at runtime. This could be enabled only for debug
builds. So you could quickly make changes during development, and
then compile everything statically for maximum speed for
production.

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

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

So, what does everyone else think?

May 31 2014
"Dylan Knutson" <tcdknutson gmail.com> writes:
Firstly, wow, the site looks beautiful. It has an air of
professionality to it, but stays minimal and to the point. I
think it'd be best if there was a code example above the fold
though (e.g. how basically every programming language website
does it nowadays), such as the word length snippet on the index
of dlang.org as of now.

Maybe it'd be good to have something about CTFE/more on templates
in the "Convenience" or "Power" section, as that has gotten much
more useful in the language the past year or two. Also, I assume
a good amount of work has to be done porting the rest of the site
over (the community and documentation sections don't seem to be
implemented).

Again, fantastic job :) it's great to see people taking
initiative. Hopefully dlang.org can get a facelift in the near
future. I'd be happy to spend some time working on porting more
of the site if it gets a "green light" from upper management to
be a replacement.

May 31 2014
"w0rp" <devw0rp gmail.com> writes:
On Saturday, 31 May 2014 at 20:01:50 UTC, Dylan Knutson wrote:
Firstly, wow, the site looks beautiful. It has an air of
professionality to it, but stays minimal and to the point. I
think it'd be best if there was a code example above the fold
though (e.g. how basically every programming language website
does it nowadays), such as the word length snippet on the index
of dlang.org as of now.

Yeah, that's why I was mentioning something about hosting drepl
on the site. One of the first things you see should be D code you

Maybe it'd be good to have something about CTFE/more on
templates in the "Convenience" or "Power" section, as that has
gotten much more useful in the language the past year or two.
Also, I assume a good amount of work has to be done porting the
rest of the site over (the community and documentation sections
don't seem to be implemented).

I just copied the text from the current website for now. I'm not
a great copy writer myself. Someone else could surely do a better
job of that.

Again, fantastic job :) it's great to see people taking
initiative. Hopefully dlang.org can get a facelift in the near
future. I'd be happy to spend some time working on porting more
of the site if it gets a "green light" from upper management to
be a replacement.

Cool. I'll glady copy a bunch of pages into diet templates or
whatever myself. I kind of need to do some of that anyway to make
sure everything fits on the page as it should.

May 31 2014
"Meta" <jared771 gmail.com> writes:
The flat design looks nice, but I really dislike the choice of
background colour. It's bland and clashes quite badly with the
white of the menu and content box.

May 31 2014
"Meta" <jared771 gmail.com> writes:
On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:
The flat design looks nice, but I really dislike the choice of
background colour. It's bland and clashes quite badly with the
white of the menu and content box.

For comparison, here's two images. One is the site with the
background as the current gradient image, the second is the site
with a background colour that matches your logo. Neither of them
is particularly appealing, either, unfortunately.

May 31 2014
"Meta" <jared771 gmail.com> writes:
On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:
On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:
The flat design looks nice, but I really dislike the choice of
background colour. It's bland and clashes quite badly with the
white of the menu and content box.

For comparison, here's two images. One is the site with the
background as the current gradient image, the second is the
site with a background colour that matches your logo. Neither
of them is particularly appealing, either, unfortunately.

Whoops. http://imgur.com/oSHfFek,Mc81UYM

May 31 2014
"w0rp" <devw0rp gmail.com> writes:
On Saturday, 31 May 2014 at 20:38:41 UTC, Meta wrote:
On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:
On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:
The flat design looks nice, but I really dislike the choice
of background colour. It's bland and clashes quite badly with
the white of the menu and content box.

For comparison, here's two images. One is the site with the
background as the current gradient image, the second is the
site with a background colour that matches your logo. Neither
of them is particularly appealing, either, unfortunately.

Whoops. http://imgur.com/oSHfFek,Mc81UYM

Yes, a darker background does look quite nice.

May 31 2014
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2014-05-31 at 20:40 +0000, w0rp via Digitalmars-d wrote:
On Saturday, 31 May 2014 at 20:38:41 UTC, Meta wrote:
On Saturday, 31 May 2014 at 20:38:05 UTC, Meta wrote:
On Saturday, 31 May 2014 at 20:12:06 UTC, Meta wrote:
The flat design looks nice, but I really dislike the choice
of background colour. It's bland and clashes quite badly with
the white of the menu and content box.

For comparison, here's two images. One is the site with the
background as the current gradient image, the second is the
site with a background colour that matches your logo. Neither
of them is particularly appealing, either, unfortunately.

Whoops. http://imgur.com/oSHfFek,Mc81UYM

Yes, a darker background does look quite nice.

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

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

May 31 2014
Jacob Carlborg <doob me.com> writes:
On 01/06/14 07:50, Russel Winder via Digitalmars-d wrote:

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

I tried and changed the background color of the #page-wrapper element to
#CCCCCC. I think that looks good, although I usually prefer lighter themes.

--
/Jacob Carlborg

Jun 02 2014
"w0rp" <devw0rp gmail.com> writes:
On Monday, 2 June 2014 at 12:42:02 UTC, Jacob Carlborg wrote:
On 01/06/14 07:50, Russel Winder via Digitalmars-d wrote:

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

I tried and changed the background color of the #page-wrapper
element to #CCCCCC. I think that looks good, although I usually
prefer lighter themes.

By the way, feel free to contribute to development of the new
site if you want to, and this goes for everyone who's interested
in helping out. https://github.com/w0rp/new-dlang.org

I'm currently in the process of breaking down the change log into
smaller pages, as the change log was getting near to 1MB of HTML.
At this point, working on anything but the change log page could

Jun 02 2014
"Kapps" <opantm2+spam gmail.com> writes:
On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:
After watching Andrei's keynote where he was asking for help,
and noticing that there wasn't any proof of someone working on
this, I took charge.

http://w0rp.com:8010/

That's the design in the form of a single page website running
on my Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I definitely like it. It scales fairly nicely, and works on high
DPI screens very nicely thanks to the lack of non-svg images
(excluding the Twitter bar which is somewhat lower quality
because it uses low-res pngs for avatars). If the logo gets
replaced, I'd like to see it remain SVG.

One thing that's a bit broken is that "Modern convenience.
Modelling power. Native efficiency." wraps to put "efficiency."
on a different line. Perhaps the text should be made smaller
there. Another thing that I'd like to see is a much more
this redesign, but a prominent download button is one of the most
important things when you're trying to get someone to try
something, right after a useful code sample (ideally with the
mentioned REPL).

May 31 2014
"w0rp" <devw0rp gmail.com> writes:
On Saturday, 31 May 2014 at 20:52:56 UTC, Kapps wrote:
One thing that's a bit broken is that "Modern convenience.
Modelling power. Native efficiency." wraps to put "efficiency."
on a different line. Perhaps the text should be made smaller
there. Another thing that I'd like to see is a much more
most important things when you're trying to get someone to try
something, right after a useful code sample (ideally with the
mentioned REPL).

top could be another colour. Maybe next to the REPL it can say,

May 31 2014
FG <home fgda.pl> writes:
On 2014-05-31 22:52, Kapps wrote:
One thing that's a bit broken is that "Modern convenience. Modelling power.
Native efficiency." wraps to put "efficiency." on a different line. Perhaps the
text should be made smaller there.

Or just put nbsp between Native and efficiency.

As for page background -- yes, it might be a bit too close to the color of the
article, especially since there are no borders around it. Works fine here but
in worse lighting conditions and on poor displays the contrast should be
higher, say, #c0c0c0 instead of the current #d7d6d6.

Jun 01 2014
On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:
After watching Andrei's keynote where he was asking for help,
and noticing that there wasn't any proof of someone working on
this, I took charge.

http://w0rp.com:8010/

That's the design in the form of a single page website running
on my Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I would like to keep going with this and just redesign the
whole website. A few points worth noting.

* This is entirely a vibe.d website. (See the source.)
* For pages, DDoc is replaced with diet templates.
* I would still use ddox for generating library documentation.
* The page is mostly held together with Bootstrap, which is
very good.
* The page is most of the way to being responsive (design
sense), as it should be.
* The module in the middle is missing, I'd use some future
version of Nowak's drepl and put a REPL right there on the
front page.
* The logo is something I quickly put together with InkScape.
Look at it as "please insert better logo here."

I encourage the use of diet over DDoc because it is simpler to
insert dynamic content in the page, especially so for vibe.d.
The support for doing conditional things or loops based on any
dynamic content we can think of is right there in vibe.d.

Now unfortunately, I have two major complaints, for vibe.d and
D itself.

For vibe.d, I can't think of a way to make changes to diet
templates without recompiling the whole site. This doesn't seem
so bad, given that compilation speed is very fast, but it
builds up. This is because the process of experimenting with
HTML becomes.

1. Make a change.
2. Recompile the whole program in a matter of seconds.
3. Refresh the browser window.

Those seconds in between making a change and seeing the results
really build up over time. It's probably hard to describe
without trying it yourself, but trust me, it matters. This is
the kind of thing I have recently fought against at work, and
it was well worth it. I replaced a Compass filesystem monitor
with an even slightly broken libsass CPython compiler which
compiled SCSS based on modification times. The couple seconds
of difference has definitely improved the day-to-day life of
myself and the web designer I work with.

This could be avoided if there was perhaps a way to rebuild
diet templates at runtime. This could be enabled only for debug
builds. So you could quickly make changes during development,
and then compile everything statically for maximum speed for
production.

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

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

So, what does everyone else think?

I love you. Will you marry me ?

May 31 2014
"Kiith-Sa" <kiithsacmp gmail.com> writes:
On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:
After watching Andrei's keynote where he was asking for help,
and noticing that there wasn't any proof of someone working on
this, I took charge.

http://w0rp.com:8010/

That's the design in the form of a single page website running
on my Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I would like to keep going with this and just redesign the
whole website. A few points worth noting.

* This is entirely a vibe.d website. (See the source.)
* For pages, DDoc is replaced with diet templates.
* I would still use ddox for generating library documentation.
* The page is mostly held together with Bootstrap, which is
very good.
* The page is most of the way to being responsive (design
sense), as it should be.
* The module in the middle is missing, I'd use some future
version of Nowak's drepl and put a REPL right there on the
front page.
* The logo is something I quickly put together with InkScape.
Look at it as "please insert better logo here."

I encourage the use of diet over DDoc because it is simpler to
insert dynamic content in the page, especially so for vibe.d.
The support for doing conditional things or loops based on any
dynamic content we can think of is right there in vibe.d.

Now unfortunately, I have two major complaints, for vibe.d and
D itself.

For vibe.d, I can't think of a way to make changes to diet
templates without recompiling the whole site. This doesn't seem
so bad, given that compilation speed is very fast, but it
builds up. This is because the process of experimenting with
HTML becomes.

1. Make a change.
2. Recompile the whole program in a matter of seconds.
3. Refresh the browser window.

Those seconds in between making a change and seeing the results
really build up over time. It's probably hard to describe
without trying it yourself, but trust me, it matters. This is
the kind of thing I have recently fought against at work, and
it was well worth it. I replaced a Compass filesystem monitor
with an even slightly broken libsass CPython compiler which
compiled SCSS based on modification times. The couple seconds
of difference has definitely improved the day-to-day life of
myself and the web designer I work with.

This could be avoided if there was perhaps a way to rebuild
diet templates at runtime. This could be enabled only for debug
builds. So you could quickly make changes during development,
and then compile everything statically for maximum speed for
production.

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

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

So, what does everyone else think?

Looks better than what we have now.

Doesn't look as good/to the point/'new' as e.g.
http://www.rust-lang.org/
or https://www.dartlang.org/ , I suspect the main problem is
content of the
front page (wall of text, 'too much stuff' instead of simple
short points), not as much design. I'd also suggest experimenting
with a less "regular" layout.

May 31 2014
"w0rp" <devw0rp gmail.com> writes:
On Saturday, 31 May 2014 at 22:54:28 UTC, Kiith-Sa wrote:
Looks better than what we have now.

Doesn't look as good/to the point/'new' as e.g.
http://www.rust-lang.org/
or https://www.dartlang.org/ , I suspect the main problem is
content of the
front page (wall of text, 'too much stuff' instead of simple
short points), not as much design. I'd also suggest
experimenting with a less "regular" layout.

I think the trick is to have very brief 'above the fold' content.
This trick is used by a lot of news publications and several
websites. I think if we put a tagline and just a couple of points
at the top of the page, then put details below the fold, it would
look cleaner. I think Dart presents itself a lot better in that
manner. When you are at the top you see just a little bit of
information. As you scroll down a tour of the language is
revealed to you.

May 31 2014
Rikki Cattermole <alphaglosined gmail.com> writes:
On 1/06/2014 7:49 a.m., w0rp wrote:
After watching Andrei's keynote where he was asking for help, and
noticing that there wasn't any proof of someone working on this, I took
charge.

http://w0rp.com:8010/

That's the design in the form of a single page website running on my
Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I would like to keep going with this and just redesign the whole
website. A few points worth noting.

* This is entirely a vibe.d website. (See the source.)
* For pages, DDoc is replaced with diet templates.
* I would still use ddox for generating library documentation.
* The page is mostly held together with Bootstrap, which is very good.
* The page is most of the way to being responsive (design sense), as it
should be.
* The module in the middle is missing, I'd use some future version of
Nowak's drepl and put a REPL right there on the front page.
* The logo is something I quickly put together with InkScape. Look at it
as "please insert better logo here."

I encourage the use of diet over DDoc because it is simpler to insert
dynamic content in the page, especially so for vibe.d. The support for
doing conditional things or loops based on any dynamic content we can
think of is right there in vibe.d.

+1

Now unfortunately, I have two major complaints, for vibe.d and D itself.

For vibe.d, I can't think of a way to make changes to diet templates
without recompiling the whole site. This doesn't seem so bad, given that
compilation speed is very fast, but it builds up. This is because the
process of experimenting with HTML becomes.

1. Make a change.
2. Recompile the whole program in a matter of seconds.
3. Refresh the browser window.

Those seconds in between making a change and seeing the results really
build up over time. It's probably hard to describe without trying it
yourself, but trust me, it matters. This is the kind of thing I have
recently fought against at work, and it was well worth it. I replaced a
Compass filesystem monitor with an even slightly broken libsass CPython
compiler which compiled SCSS based on modification times. The couple
seconds of difference has definitely improved the day-to-day life of
myself and the web designer I work with.

This could be avoided if there was perhaps a way to rebuild diet
templates at runtime. This could be enabled only for debug builds. So
you could quickly make changes during development, and then compile
everything statically for maximum speed for production.

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

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

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

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

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

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

So, what does everyone else think?

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

[0]

May 31 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 1 June 2014 at 03:26:30 UTC, Rikki Cattermole wrote:
The problem with diet is it compiles directly to D code, hence
forth its not really possible at the moment.
However as I believe Sonke has said previous it is out of scope
of Vibe. Its actually in the scope of Cmsed instead.

from what I can ascertain reliably we need shared library
support. While this is doable upon Linux, it isn't on Windows.
Until its available on Windows I will not use it.

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

I would also consider using a different template engine entirely,
one which is less powerful but which can be automatically
recompiled at runtime. I would consider something with diet
syntax, but where only some of the D language parts actually
work. (The '-' syntax parts.)

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

for lower memory build profiles. As far as I recall, I believe
the memory usage comes from the philosophy that you can malloc,
malloc, malloc, then exit the process for speed. I think it was
freeing some memory and so on which would reduce build speed. I
might be talking nonsense, but it would be nice to have an option
to reduce build speed and also reduce memory usage. Of course,
having the best of both worlds is always great.

Jun 01 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 01.06.2014 11:54, schrieb w0rp:
On Sunday, 1 June 2014 at 03:26:30 UTC, Rikki Cattermole wrote:
The problem with diet is it compiles directly to D code, hence forth
its not really possible at the moment.
However as I believe Sonke has said previous it is out of scope of
Vibe. Its actually in the scope of Cmsed instead.

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

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

I would also consider using a different template engine entirely, one
which is less powerful but which can be automatically recompiled at
runtime. I would consider something with diet syntax, but where only
some of the D language parts actually work. (The '-' syntax parts.)

I thought there was a ticket open to let Diet templates automatically
recompile in the background for development, but didn't find one - newly
opened ticket: [1]. I definitely consider that particular feature within
the scope of vibe.d (in contrast to dynamic loading of high level
components), but I'm currently lacking the time to implement it myself.

For the big text content pages, it may make sense to stay with DDOC and
use the DDOC processor of DDOX [2]. Another possibility would be to use
enhanced Markdown. Unfortunately the Markdown compiler in vibe.d doesn't
currently support tables, though (although those can of course be
inserted using inline HTML).

[1]: https://github.com/rejectedsoftware/vibe.d/issues/676
[2]: https://github.com/rejectedsoftware/ddox/blob/master/source/ddox/ddoc.d

Jun 01 2014
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2014-05-31 at 19:49 +0000, w0rp via Digitalmars-d wrote:
After watching Andrei's keynote where he was asking for help, and
noticing that there wasn't any proof of someone working on this,
I took charge.

http://w0rp.com:8010/

I have to admit my initial reaction on seeing this was: oh no not
another bland "me too" Angular/Ember/Drupal style three-column,
client-side, flat menu system more or less like every other new site
created because that is the fashionable style of the moment. On the
other hand others like it so, go with it.

For me the issue is branding. Whatever it's faults, the current
dlang.org does have a unique style to it.

I think having humour on the site is a good thing, cf. the D figure on
dlang.org. It would be good to do more with the D figure, or some other
mascot. Java has Duke, Go has the gopher, there is a lot of mileage in
having such a character, not only for the website, but also for
presentations. Having a mascot that can be used for humour helps
massively. When Sun controlled Duke it was all a bit tedious, once the
mascot was released, many people created many variants leading to an
extremely useful tool for enlivening presentations.

That's the design in the form of a single page website running on
my Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I would like to keep going with this and just redesign the whole
website. A few points worth noting.

* This is entirely a vibe.d website. (See the source.)

Seems entirely reasonable in the context :-) In fact it would be worth
ensuring this fact is front and centre so that anyone alighting on the
site knows it is vibe.d, i.e. D, powered.

* For pages, DDoc is replaced with diet templates.
* I would still use ddox for generating library documentation.
* The page is mostly held together with Bootstrap, which is very
good.
* The page is most of the way to being responsive (design sense),
as it should be.
* The module in the middle is missing, I'd use some future
version of Nowak's drepl and put a REPL right there on the front
page.

Go has the Go playground rather than trying to create a REPL per se (cf.
http://golang.org/). Despite the fashion for REPLs, I find them
irritating. I am much more in favour of a tiny lightweight edit and a
fast compile/execution of the editor content. Another example of this is
IPython notebooks. Python and IPython have REPLs, which have their uses,
but the IPython notebooks are modern literate programming. Well actually
their main use is for writing documents (especially scientific papers to
be shipped) that include executable code. It is an idea that has totally
won over many in bioinformatics, HPC, and data sciences in general. It
wouldn't surprise me if Go could do something similar in the near
future.

* The logo is something I quickly put together with InkScape.
Look at it as "please insert better logo here."

Just use the logo from dlang.org? It is effectively, and possibly
actually, the official logo.

I encourage the use of diet over DDoc because it is simpler to
insert dynamic content in the page, especially so for vibe.d. The
support for doing conditional things or loops based on any
dynamic content we can think of is right there in vibe.d.

Now unfortunately, I have two major complaints, for vibe.d and D
itself.

For vibe.d, I can't think of a way to make changes to diet
templates without recompiling the whole site. This doesn't seem
so bad, given that compilation speed is very fast, but it builds
up. This is because the process of experimenting with HTML
becomes.

Not so bad for releases, but terrible for development.

Grails and Django go to great lengths to ensure that the development
environment is entirely local to the development machine and has
dynamic, and fast, update of all content. So as soon as you write back a
file to the filestore the development server gets notified and reloads
the site as needed. This makes for very fast evolution of things â€” but I
am probably "teaching grandmother to such eggs" here.

1. Make a change.
2. Recompile the whole program in a matter of seconds.
3. Refresh the browser window.

Those seconds in between making a change and seeing the results
really build up over time. It's probably hard to describe without
trying it yourself, but trust me, it matters. This is the kind of
thing I have recently fought against at work, and it was well
worth it. I replaced a Compass filesystem monitor with an even
slightly broken libsass CPython compiler which compiled SCSS
based on modification times. The couple seconds of difference has
definitely improved the day-to-day life of myself and the web
designer I work with.

I can attest to the pain of a system that takes 5s or 6s to refresh, it
becomes horribly painful. To the extent of giving up and switching
infrastructure.

This could be avoided if there was perhaps a way to rebuild diet
templates at runtime. This could be enabled only for debug
builds. So you could quickly make changes during development, and
then compile everything statically for maximum speed for
production.

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

Isn't the problem here that you are having to deploy in order to
develop? Maybe I am just missing something, but it sounds as though
there isn't actually a development workflow, just a create and release
one.

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

So, what does everyone else think?

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

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

May 31 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 1 June 2014 at 05:46:57 UTC, Russel Winder via
Digitalmars-d wrote:
The complaint I have for D is that too much memory is consumed
for building D programs. The memory usage made it impossible
for me to build the vibe.d site on my Linode, which the site
above linked is running off of. The only way I was able to get
the site to run on my Debian Wheezy server was to install a
bunch of libraries from Debian testing, compile the program on
my Arch Linux desktop, and then upload and run it on my server.

Isn't the problem here that you are having to deploy in order to
develop? Maybe I am just missing something, but it sounds as
though
there isn't actually a development workflow, just a create and
release
one.

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

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

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

Jun 01 2014
FG <home fgda.pl> writes:
On 2014-06-01 07:46, Russel Winder via Digitalmars-d wrote:
I think having humour on the site is a good thing, cf. the D figure on
dlang.org. It would be good to do more with the D figure, or some other
mascot. Java has Duke, Go has the gopher [...]

Please, no. Whatever you do, don't create something this hideous. :)
http://blog.golang.org/gopher

Jun 01 2014
"w0rp" <devw0rp gmail.com> writes:
I just updated the site. Here are the main changes.

* The background is now dark. I tried a linear-gradient for a
little bit, but it made scrolling down the page much, much
* The column on the right gets fixed when you scroll down, but
the Bootstrap tool for this has a bug when you scroll all the way
to the bottom some times which I need to get fixed.

(Redirecting like this is vital for SEO.)

I want to fix that scrolling bug, account for resizing a window
smaller than the length of the right column (I've seen this issue
button on the top a bit more colour, and get a nice gradient in
which doesn't slow the page down. It was looking pretty good, but
I absolutely will not use linear-gradient on the page after I saw
how it ruined smooth scrolling.

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

- import dlang.toc;

append content
...

...

append extra-sidebar
- toc();

I bet I can make this syntax possible.

Out for now.

Jun 01 2014
On Sunday, 1 June 2014 at 13:29:38 UTC, w0rp wrote:
I just updated the site. Here are the main changes.

<snip>

Had to force a refresh to see the changes. I can't decide if I
like the dark background better or worse. Either looks fine
though.

Jun 01 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 1 June 2014 at 18:42:51 UTC, Brad Anderson wrote:
On Sunday, 1 June 2014 at 13:29:38 UTC, w0rp wrote:
I just updated the site. Here are the main changes.

<snip>

Had to force a refresh to see the changes. I can't decide if I
like the dark background better or worse. Either looks fine
though.

You just reminded me to put in a query string version hack at
some point. I typically use something like
?v=<epoch_of_server_start> or similar.

Jun 01 2014
"w0rp" <devw0rp gmail.com> writes:
https://github.com/w0rp/new-dlang.org/blob/master/src/dlang/toc.d

templates.

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

|!= toc.write("Title")

There are functions named 'h1' to 'h6' to use, and it works. Now
it should be dead simple to write headings and generate a table
of contents for a number of pages.

Jun 01 2014
Jacob Carlborg <doob me.com> writes:
On 01/06/14 21:56, w0rp wrote:

You just reminded me to put in a query string version hack at some
point. I typically use something like ?v=<epoch_of_server_start> or
similar.

That's not reliable. It's usually assets that are the problem, CSS, JS,
images and so on. They should have a unique hash based on the content
appended to the filename. Then you can have really long cache timeout
(or what it's called) on those files.

--
/Jacob Carlborg

Jun 02 2014
"Rusty D. Shackleford" <nanr9d gmail.com> writes:
On Sunday, 1 June 2014 at 13:29:38 UTC, w0rp wrote:
I just updated the site. Here are the main changes.

* The background is now dark. I tried a linear-gradient for a
little bit, but it made scrolling down the page much, much
* The column on the right gets fixed when you scroll down, but
the Bootstrap tool for this has a bug when you scroll all the
way to the bottom some times which I need to get fixed.

I find the dark background pretty hard on the eyes in contrast
with the light foreground, maybe it's just me but I preferred the
light one.

Jun 01 2014
"Kagamin" <spam here.lot> writes:
Hmm... doesn't scale well, the main text remains crammed into
fixed 1/3 of the page width, the rest is empty space.

Jun 02 2014
"w0rp" <devw0rp gmail.com> writes:
On Monday, 2 June 2014 at 19:16:04 UTC, Kagamin wrote:
Hmm... doesn't scale well, the main text remains crammed into
fixed 1/3 of the page width, the rest is empty space.

There should be a maximum width on the text you read on a page.
decrease.

Jun 03 2014
"Kagamin" <spam here.lot> writes:
Shouldn't it be measured in characters instead of percentage of
page width?

Jun 03 2014
"w0rp" <devw0rp gmail.com> writes:
I have updated the site and the repository with all of the D
changelogs split into their own pages. I had to reformat a few
things, primarily example code, so it would fit nicely in smaller
column sizes. I marked sections with headings so it fits into a
highlighting, as I'm not sure what to use for that.

http://w0rp.com:8010/changelog

Here is what I've noticed so far that's good about the diet
templates.

1. The template syntax, taken from Jade, is easy to understand
and clean.

However, with the good comes the bad.

1. If you are recompiling one template, you are recompiling *all*
of them. I'm getting closer to 100 templates, and it takes
seconds to compile.
2. Compiling many templates allocates like crazy during compile
time and eats memory like a hog. It takes *5GB* of RAM to compile
all of these templates.

It seems like the vibe.d diet templates take heap allocation
during compilation time way, way too far, to the point of them
being impractical to use for large websites. Somewhere around 100
templates is something I would expect for a reasonably sized
website.

So I have a plea or two for vibe.d

In addition to recompiling diet templates automatically during
development, which has been mentioned before, I believe there
should be an option to defer compilation of a template the first
time, during development, until you view a page using it for the
first time. This woud solve the slower compilation issue, because
then you'd only pay for what you used.

Second, something must be done about memory allocation during
compilation of diet templates. There's too much going on there.

That's it for now.

Jun 09 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.06.2014 02:18, schrieb w0rp:
I have updated the site and the repository with all of the D changelogs
split into their own pages. I had to reformat a few things, primarily
example code, so it would fit nicely in smaller column sizes. I marked
thing that's missing is syntax highlighting, as I'm not sure what to use
for that.

http://w0rp.com:8010/changelog

Here is what I've noticed so far that's good about the diet templates.

1. The template syntax, taken from Jade, is easy to understand and clean.

However, with the good comes the bad.

1. If you are recompiling one template, you are recompiling *all* of
them. I'm getting closer to 100 templates, and it takes seconds to compile.

Sounds kind of like an ironic joke when viewed from a C++ background ;)

But yes, it's definitely not what you want to have for D. I'm not sure
how much can be done about that, though - except from rewriting the CTFE
engine with performance in mind (maybe even using a JIT compiler). Or
maybe it's possible to be more liberal with algorithmic optimizations
when the CTFE memory usage brought to a reasonable level.

2. Compiling many templates allocates like crazy during compile time and
eats memory like a hog. It takes *5GB* of RAM to compile all of these
templates.

Yes, which is why (at least with the current compiler front end) I'd
strongly recommend to put long text content in a different format that
is inserted at runtime (e.g. DDOC or Markdown).

It seems like the vibe.d diet templates take heap allocation during
compilation time way, way too far, to the point of them being
impractical to use for large websites. Somewhere around 100 templates is
something I would expect for a reasonably sized website.

It's not heap allocations. The problem is that during CTFE, currently
basically every variable change allocates memory that is never freed
again. I've used a few tricks to get the memory usage down (which is why
the Diet compiler source code doesn't look very pretty), but basically
the only way to get reasonable memory use is to fix the D front end.

So I have a plea or two for vibe.d

In addition to recompiling diet templates automatically during
development, which has been mentioned before, I believe there should be
an option to defer compilation of a template the first time, during
development, until you view a page using it for the first time. This
woud solve the slower compilation issue, because then you'd only pay for
what you used.

That would probably even be a side-effect of the implementation of
separately compiled templates (eagerly compiling them will require some

Second, something must be done about memory allocation during
compilation of diet templates. There's too much going on there.

That's it for now.


Jun 10 2014
"w0rp" <devw0rp gmail.com> writes:
On Tuesday, 10 June 2014 at 08:12:53 UTC, SÃ¶nke Ludwig wrote:
It's not heap allocations. The problem is that during CTFE,
currently basically every variable change allocates memory that
is never freed again. I've used a few tricks to get the memory
usage down (which is why the Diet compiler source code doesn't
look very pretty), but basically the only way to get reasonable
memory use is to fix the D front end.

Indeed, this is a front end issue. I'm considering switching to
markdown files loaded at runtime for many pages. So I can create
only a few diet templates for basic layout, two column, generic
changelog template, etc, and then load Markdown content at
automatically.

Jun 10 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.06.2014 12:25, schrieb w0rp:
On Tuesday, 10 June 2014 at 08:12:53 UTC, SÃ¶nke Ludwig wrote:
It's not heap allocations. The problem is that during CTFE, currently
basically every variable change allocates memory that is never freed
again. I've used a few tricks to get the memory usage down (which is
why the Diet compiler source code doesn't look very pretty), but
basically the only way to get reasonable memory use is to fix the D
front end.

Indeed, this is a front end issue. I'm considering switching to markdown
files loaded at runtime for many pages. So I can create only a few diet
templates for basic layout, two column, generic changelog template, etc,
and then load Markdown content at runtime and parse Markdown for

If you go down the Markdown route*, let's extend the
vibe.textfilter.markdown module to output structural information.
Writing a Markdown parser in a way that doesn't use a cascade of regex
patterns is definitely nothing I'd recommend anyone to try to do, unless
absolutely necessary - it's awful.

* Are there any other opinions on this? I remember that there have been
some strong proponents of using DDOC for things, so it would be bad if
in the end Markdown were to be dropped, after all of the work has
already been done. Personally I'd strongly favor Markdown, though.

Jun 10 2014
"Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 June 2014 at 10:42:14 UTC, SÃ¶nke Ludwig wrote:
* Are there any other opinions on this? I remember that there
have been some strong proponents of using DDOC for things, so
it would be bad if in the end Markdown were to be dropped,
after all of the work has already been done. Personally I'd
strongly favor Markdown, though.

DDOC was promoted because of dog-fooding rationale but I believe
it has unacceptable learning curve and negatively impacts
documentation contribution.

Jun 10 2014
"w0rp" <devw0rp gmail.com> writes:
On Tuesday, 10 June 2014 at 11:09:23 UTC, Dicebot wrote:
On Tuesday, 10 June 2014 at 10:42:14 UTC, SÃ¶nke Ludwig wrote:
* Are there any other opinions on this? I remember that there
have been some strong proponents of using DDOC for things, so
it would be bad if in the end Markdown were to be dropped,
after all of the work has already been done. Personally I'd
strongly favor Markdown, though.

DDOC was promoted because of dog-fooding rationale but I
believe it has unacceptable learning curve and negatively
impacts documentation contribution.

I think the key advantage for Markdown is that it's well
understood by a larger community, (GitHub, Stack Overflow,
Reddit, etc.) so it would likely encourage contribution to
editing pages on the website. It's also just has very nice syntax
for writing articles with, although I know how frustrating it is
to write a parser for it. (You have to accept stuff which is
sometimes HTML, sometimes not.)

The library documentation will still be DDoc generated, as that's
the best tool for that, just styled differently.

Jun 10 2014
Jacob Carlborg <doob me.com> writes:
On 10/06/14 13:09, Dicebot wrote:

DDOC was promoted because of dog-fooding rationale but I believe it has
unacceptable learning curve and negatively impacts documentation
contribution.

I think Ddoc is fine for API documentation, but not for designing a web
site.

--
/Jacob Carlborg

Jun 10 2014
"Kiith-Sa" <kiithsacmp gmail.com> writes:
On Tuesday, 10 June 2014 at 10:42:14 UTC, SÃ¶nke Ludwig wrote:
Am 10.06.2014 12:25, schrieb w0rp:
On Tuesday, 10 June 2014 at 08:12:53 UTC, SÃ¶nke Ludwig wrote:
It's not heap allocations. The problem is that during CTFE,
currently
basically every variable change allocates memory that is
never freed
again. I've used a few tricks to get the memory usage down
(which is
why the Diet compiler source code doesn't look very pretty),
but
basically the only way to get reasonable memory use is to fix
the D
front end.

Indeed, this is a front end issue. I'm considering switching
to markdown
files loaded at runtime for many pages. So I can create only a
few diet
templates for basic layout, two column, generic changelog
template, etc,
and then load Markdown content at runtime and parse Markdown
for

If you go down the Markdown route*, let's extend the
vibe.textfilter.markdown module to output structural
information. Writing a Markdown parser in a way that doesn't
use a cascade of regex patterns is definitely nothing I'd
recommend anyone to try to do, unless absolutely necessary -
it's awful.

* Are there any other opinions on this? I remember that there
have been some strong proponents of using DDOC for things, so
it would be bad if in the end Markdown were to be dropped,
after all of the work has already been done. Personally I'd
strongly favor Markdown, though.

Definitely support Markdown.

DDoc is extremely discouraging/making bad first impression on
newbies, especially for people who want to write web content.

(But I'd recommend extended GitHub-like markdown if possible,
plain markdown is pretty bare bones. Personally I use
ReStructuredText but I think the GitHub markdown is pretty good
and most potential contributors can already write it without
learning a new format.

Jun 10 2014
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-06-10 at 12:31 +0000, Kiith-Sa via Digitalmars-d wrote:
On Tuesday, 10 June 2014 at 10:42:14 UTC, SÃ¶nke Ludwig wrote:

[â€¦]
* Are there any other opinions on this? I remember that there
have been some strong proponents of using DDOC for things, so
it would be bad if in the end Markdown were to be dropped,
after all of the work has already been done. Personally I'd
strongly favor Markdown, though.

Isn't DDoc for generating API documentation is the vein of Doxygen,
(albeit technical) webpages?

Definitely support Markdown.

DDoc is extremely discouraging/making bad first impression on
newbies, especially for people who want to write web content.

(But I'd recommend extended GitHub-like markdown if possible,
plain markdown is pretty bare bones. Personally I use
ReStructuredText but I think the GitHub markdown is pretty good
and most potential contributors can already write it without
learning a new format.

The Groovy community initially tried using GrailsDoc â€“ not an API
documentation system, but a way of writing general documentation that
could easily access API documentation. However, the move now appears to
be to ASCIIDoc using the ASCIIDoctor toolchain.

As for ReStructured Text, I find Markdown beats it for short pages, but
it beats Markdown easily for bigger documents. The Sphinx system may not
be appropriate for D, but it works very well.

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

Jun 10 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.06.2014 14:31, schrieb Kiith-Sa:
(But I'd recommend extended GitHub-like markdown if possible, plain
markdown is pretty bare bones. Personally I use ReStructuredText but I
think the GitHub markdown is pretty good and most potential contributors
can already write it without learning a new format.

Agreed. The Markdown parser in vibe.d does support some of the GitHub
extensions, but still lacks some useful things like tables.

Jun 10 2014
"w0rp" <devw0rp gmail.com> writes:
On Tuesday, 10 June 2014 at 14:50:51 UTC, SÃ¶nke Ludwig wrote:
Am 10.06.2014 14:31, schrieb Kiith-Sa:
(But I'd recommend extended GitHub-like markdown if possible,
plain
markdown is pretty bare bones. Personally I use
ReStructuredText but I
think the GitHub markdown is pretty good and most potential
contributors
can already write it without learning a new format.

Agreed. The Markdown parser in vibe.d does support some of the
GitHub extensions, but still lacks some useful things like
tables.

I can definitely live without Markdown style tables. I'm happy
enough to write HTML for that.

Jun 10 2014
"w0rp" <devw0rp gmail.com> writes:
I thought I'd post an update on this work so I don't leave any

I haven't had the time in the last week or so to work on this as
I have been very busy recently with other responsibilities. With
my day job in particular, I will be in Berlin most of next week
hosting a conference with my company. Because it's a small world,
by pure coincidence Sociomantic are actually sponsoring this
conference. (I doubt the marketing guys talk to the D programmers
that much, though.)

However, after I get back I will defintely work on this redesign
some more. Unless somebody pins me down, I'll keep going with it.
I only just realised that I made the terrible mistake of not
pushing my most recent changes, so you can find them now on
GitHub.

I started working on discovering Markdown files at runtime for
filling in a sections of pages, like center part of changelog
automatically. Because the prospect of parsing HTML myself scares
me, I just copied in Adam D Ruppe's DOM library for that. I hope
that I have properly attributed the authors for that code, please
otherwise.

The early result of that I think has been pretty good. I can edit
a file and see a change pretty quickly. I lost the functions I
was using to generating the Bugzilla links, but I'm going to
page redirect to the right place, just so I can make my Markdown
files a little smaller. The amount of memory consumed while
compiling is better, going from something like 2GB to 1.2GB,
because there aren't tons of Diet templates to build in anymore.
The Markdown parsing is just the library functionality that comes
with vibe.d.

I totally have not converted all of the pages from Diet to
Markdown yet. In fact, if you run the site as is now, you can't
see any of the changelog pages except 2.000 anymore. Plus, you
could perhaps do something involving caching files instead of
loading them from the drive all the time, but I just want
something that works for now.

So there's my update for now.

Jun 20 2014
"w0rp" <devw0rp gmail.com> writes:
I just finished translating all of the pages I have worked on so
far from diet templates to Markdown files. Now there is only one
diet layout loaded, and the rest is all Markdown files. This has
dramatically reduced the amount of memory consumed at build time.
You can see the results at the usual place at
http://w0rp.com:8010 and view the source on GitHub. I'll keep at
it and convert more pages from the main site.

Jun 29 2014
On 6/29/14, 3:15 PM, w0rp wrote:
I just finished translating all of the pages I have worked on so far
from diet templates to Markdown files. Now there is only one diet layout
loaded, and the rest is all Markdown files. This has dramatically
reduced the amount of memory consumed at build time. You can see the
results at the usual place at http://w0rp.com:8010 and view the source
on GitHub. I'll keep at it and convert more pages from the main site.

This is looking really good!

Jun 30 2014
On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:
I just finished translating all of the pages I have worked on
so far from diet templates to Markdown files. Now there is only
one diet layout loaded, and the rest is all Markdown files.
This has dramatically reduced the amount of memory consumed at
build time. You can see the results at the usual place at
http://w0rp.com:8010 and view the source on GitHub. I'll keep
at it and convert more pages from the main site.

Please use the correct logo and the correct colours. Branding is
extremely important!

http://media.sukimashita.com/d/d-5.svg

Jun 30 2014
On 6/30/14, 2:11 PM, Gary Willoughby wrote:
On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:
I just finished translating all of the pages I have worked on so far
from diet templates to Markdown files. Now there is only one diet
layout loaded, and the rest is all Markdown files. This has
dramatically reduced the amount of memory consumed at build time. You
can see the results at the usual place at http://w0rp.com:8010 and
view the source on GitHub. I'll keep at it and convert more pages from
the main site.

Please use the correct logo and the correct colours. Branding is
extremely important!

http://media.sukimashita.com/d/d-5.svg

My opinion is that the redesign preserves the spirit of the current logo
while fitting in well with the flatter look. I think someone who sees
the one logo will recognize the other in it (unlike some of the recent
proposed logos).

Jun 30 2014
"w0rp" <devw0rp gmail.com> writes:
On Monday, 30 June 2014 at 21:11:31 UTC, Gary Willoughby wrote:
On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:
I just finished translating all of the pages I have worked on
so far from diet templates to Markdown files. Now there is
only one diet layout loaded, and the rest is all Markdown
files. This has dramatically reduced the amount of memory
consumed at build time. You can see the results at the usual
place at http://w0rp.com:8010 and view the source on GitHub.
I'll keep at it and convert more pages from the main site.

Please use the correct logo and the correct colours. Branding
is extremely important!

http://media.sukimashita.com/d/d-5.svg

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design
experience. The old logo is a bit too fat and round to fit with
the new design, so I'd like something which is obviously still
the same brand, but looks a bit flatter.

Jun 30 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design experience. The
old logo is a bit too fat and round to fit with the new design, so I'd
like something which is obviously still the same brand, but looks a bit
flatter.

I just found out why your logo looks terrible on my machine, you are
using a web font in the SVG that FF isn't finding and there is no
fallback specified so I'm getting a D in Times New Roman ><

A quick solution would be to convert the glyph to curves ("Object to
Path" on the "Path" menu in Inkscape), then you will know that everyone
is seeing the same thing.

A...

Jul 01 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 01/07/2014 8:40 AM, Alix Pexton wrote:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design experience. The
old logo is a bit too fat and round to fit with the new design, so I'd
like something which is obviously still the same brand, but looks a bit
flatter.

I just found out why your logo looks terrible on my machine, you are
using a web font in the SVG that FF isn't finding and there is no
fallback specified so I'm getting a D in Times New Roman ><

A quick solution would be to convert the glyph to curves ("Object to
Path" on the "Path" menu in Inkscape), then you will know that everyone
is seeing the same thing.

A...

However, the font is Apache licensed, so to use it in a logo you would
need to purchase the Pro version for \$80 dollars. This is why I do all
my own typography!

A...

Jul 01 2014
"w0rp" <devw0rp gmail.com> writes:
On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design
experience. The
old logo is a bit too fat and round to fit with the new
design, so I'd
like something which is obviously still the same brand, but
looks a bit
flatter.

I just found out why your logo looks terrible on my machine,
you are using a web font in the SVG that FF isn't finding and
there is no fallback specified so I'm getting a D in Times New
Roman ><

A quick solution would be to convert the glyph to curves
("Object to Path" on the "Path" menu in Inkscape), then you
will know that everyone is seeing the same thing.

A...

Ah, I didn't realise the SVG was loading a font for that, I
suppose it make perfect sense. Again, no graphic design
experience.

Generally for the logo, I'm looking for someone who does know
what they are doing with Inkscape or similar tools to produce

Jul 01 2014
"w0rp" <devw0rp gmail.com> writes:
On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:
On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design
experience. The
old logo is a bit too fat and round to fit with the new
design, so I'd
like something which is obviously still the same brand, but
looks a bit
flatter.

I just found out why your logo looks terrible on my machine,
you are using a web font in the SVG that FF isn't finding and
there is no fallback specified so I'm getting a D in Times New
Roman ><

A quick solution would be to convert the glyph to curves
("Object to Path" on the "Path" menu in Inkscape), then you
will know that everyone is seeing the same thing.

A...

Ah, I didn't realise the SVG was loading a font for that, I
suppose it make perfect sense. Again, no graphic design
experience.

Generally for the logo, I'm looking for someone who does know
what they are doing with Inkscape or similar tools to produce

I'll fix that in the interim by converting the font into a shape

Jul 01 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 July 2014 13:40, w0rp via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:
On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design experience. The
old logo is a bit too fat and round to fit with the new design, so I'd
like something which is obviously still the same brand, but looks a bit
flatter.

I just found out why your logo looks terrible on my machine, you are
using a web font in the SVG that FF isn't finding and there is no fallback
specified so I'm getting a D in Times New Roman ><

A quick solution would be to convert the glyph to curves ("Object to
Path" on the "Path" menu in Inkscape), then you will know that everyone is
seeing the same thing.

A...

Ah, I didn't realise the SVG was loading a font for that, I
suppose it make perfect sense. Again, no graphic design
experience.

Generally for the logo, I'm looking for someone who does know
what they are doing with Inkscape or similar tools to produce

I'll fix that in the interim by converting the font into a shape instead.

By the way, did you get round to implementing some sort of generic
watch routine?

I've bashed together a small generic FAM - could clean it up and send
it to the vibe.d guys to fix up and make it better.

Regards
Iain

Jul 01 2014
"w0rp" <devw0rp gmail.com> writes:
On Tuesday, 1 July 2014 at 14:23:00 UTC, Iain Buclaw via
Digitalmars-d wrote:
By the way, did you get round to implementing some sort of
generic
watch routine?

I've bashed together a small generic FAM - could clean it up
and send
it to the vibe.d guys to fix up and make it better.

Regards
Iain

I did not. We are defintely writing very similar things, so if
you've got something already that does the job feel free to add
it in with a pull request or push it up to vibe.d so everyone can
benefit from it. I'm focused on getting more of the existing site
copied across and a bunch of style things at the moment.

Jul 01 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 01.07.2014 16:22, schrieb Iain Buclaw via Digitalmars-d:
On 1 July 2014 13:40, w0rp via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:
On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design experience. The
old logo is a bit too fat and round to fit with the new design, so I'd
like something which is obviously still the same brand, but looks a bit
flatter.

I just found out why your logo looks terrible on my machine, you are
using a web font in the SVG that FF isn't finding and there is no fallback
specified so I'm getting a D in Times New Roman ><

A quick solution would be to convert the glyph to curves ("Object to
Path" on the "Path" menu in Inkscape), then you will know that everyone is
seeing the same thing.

A...

Ah, I didn't realise the SVG was loading a font for that, I
suppose it make perfect sense. Again, no graphic design
experience.

Generally for the logo, I'm looking for someone who does know
what they are doing with Inkscape or similar tools to produce

I'll fix that in the interim by converting the font into a shape instead.

By the way, did you get round to implementing some sort of generic
watch routine?

I've bashed together a small generic FAM - could clean it up and send
it to the vibe.d guys to fix up and make it better.

Regards
Iain

If it works with libevent and could be fit into this API:

http://vibed.org/api/vibe.core.driver/EventDriver.watchDirectory
http://vibed.org/api/vibe.core.file/DirectoryWatcher

then that would be great! Live reloading is definitely a pretty big
deal, but I've always been overloaded with work on more fundamental
issues so far.

BTW, for the special case of Diet templates there is also this ticket:
https://github.com/rejectedsoftware/vibe.d/issues/676

Jul 01 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 July 2014 20:05, SÃ¶nke Ludwig <digitalmars-d puremagic.com> wrote:
Am 01.07.2014 16:22, schrieb Iain Buclaw via Digitalmars-d:
On 1 July 2014 13:40, w0rp via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:
On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design experience.
The
old logo is a bit too fat and round to fit with the new design, so I'd
like something which is obviously still the same brand, but looks a
bit
flatter.

I just found out why your logo looks terrible on my machine, you are
using a web font in the SVG that FF isn't finding and there is no
fallback
specified so I'm getting a D in Times New Roman ><

A quick solution would be to convert the glyph to curves ("Object to
Path" on the "Path" menu in Inkscape), then you will know that everyone
is
seeing the same thing.

A...

Ah, I didn't realise the SVG was loading a font for that, I
suppose it make perfect sense. Again, no graphic design
experience.

Generally for the logo, I'm looking for someone who does know
what they are doing with Inkscape or similar tools to produce

I'll fix that in the interim by converting the font into a shape instead.

By the way, did you get round to implementing some sort of generic
watch routine?

I've bashed together a small generic FAM - could clean it up and send
it to the vibe.d guys to fix up and make it better.

Regards
Iain

If it works with libevent and could be fit into this API:

http://vibed.org/api/vibe.core.driver/EventDriver.watchDirectory
http://vibed.org/api/vibe.core.file/DirectoryWatcher

then that would be great! Live reloading is definitely a pretty big deal,
but I've always been overloaded with work on more fundamental issues so far.

It doesn't use libevent... yet.  As I said, its bashed together so
pretty much works as a separate thread running in a while(true) { ...
sleep(x); } loop that re-compiles markdown files in the background.

For the moment on my own staging site, I've just loaded in Redis as a
memserver with a brief expiry time.

Wouldn't want to steal the limelight, but I'm over here:

http://staging.dgnu.org

Regards
Iain

Jul 01 2014
On Tuesday, 1 July 2014 at 12:40:21 UTC, w0rp wrote:
On Tuesday, 1 July 2014 at 12:38:39 UTC, w0rp wrote:
On Tuesday, 1 July 2014 at 07:40:03 UTC, Alix Pexton wrote:
On 01/07/2014 7:42 AM, w0rp wrote:

The logo on the site I'm testing is the most effective duck.

The logo is a placeholder I made with no graphic design
experience. The
old logo is a bit too fat and round to fit with the new
design, so I'd
like something which is obviously still the same brand, but
looks a bit
flatter.

I just found out why your logo looks terrible on my machine,
you are using a web font in the SVG that FF isn't finding and
there is no fallback specified so I'm getting a D in Times
New Roman ><

A quick solution would be to convert the glyph to curves
("Object to Path" on the "Path" menu in Inkscape), then you
will know that everyone is seeing the same thing.

A...

Ah, I didn't realise the SVG was loading a font for that, I
suppose it make perfect sense. Again, no graphic design
experience.

Generally for the logo, I'm looking for someone who does know
what they are doing with Inkscape or similar tools to produce

I'll fix that in the interim by converting the font into a

I did that a couple years ago: http://goo.gl/trMh6k

Jul 01 2014
On Monday, 30 June 2014 at 21:23:59 UTC, David Gileadi wrote:
My opinion is that the redesign preserves the spirit of the
current logo while fitting in well with the flatter look. I
think someone who sees the one logo will recognize the other in
it (unlike some of the recent proposed logos).

On Tuesday, 1 July 2014 at 06:42:49 UTC, w0rp wrote:
The logo is a placeholder I made with no graphic design
experience. The old logo is a bit too fat and round to fit with
the new design, so I'd like something which is obviously still
the same brand, but looks a bit flatter.

No! You must use the original D logo, this is not up for debate.
I will fight this until the end. You cannot mess about with the
brand! We must start to approach these things in a professional
and respectful manner.

The original D logo (and colours) must be used.

Jul 01 2014
"Dicebot" <public dicebot.lv> writes:
On Tuesday, 1 July 2014 at 08:34:30 UTC, Gary Willoughby wrote:
On Monday, 30 June 2014 at 21:23:59 UTC, David Gileadi wrote:
My opinion is that the redesign preserves the spirit of the
current logo while fitting in well with the flatter look. I
think someone who sees the one logo will recognize the other
in it (unlike some of the recent proposed logos).

On Tuesday, 1 July 2014 at 06:42:49 UTC, w0rp wrote:
The logo is a placeholder I made with no graphic design
experience. The old logo is a bit too fat and round to fit
with the new design, so I'd like something which is obviously
still the same brand, but looks a bit flatter.

No! You must use the original D logo, this is not up for
debate. I will fight this until the end. You cannot mess about
with the brand! We must start to approach these things in a
professional and respectful manner.

The original D logo (and colours) must be used.

Doing logo restyling together with web site update is not unheard
of. Why do you see this a big deal? As long as it is recognizable
and not fundamentally different of course. Having logo that
simply does not fit into new design is worse.

Jul 01 2014
Jacob Carlborg <doob me.com> writes:
On 2014-07-01 10:58, Dicebot wrote:

Doing logo restyling together with web site update is not unheard of.
Why do you see this a big deal? As long as it is recognizable and not
fundamentally different of course. Having logo that simply does not fit
into new design is worse.

Some companies also use different versions of their logo for different
purposes. One on the website, one on print and so on.

--
/Jacob Carlborg

Jul 01 2014
On Tuesday, 1 July 2014 at 08:34:30 UTC, Gary Willoughby wrote:
No! You must use the original D logo, this is not up for
debate. I will fight this until the end. You cannot mess about
with the brand! We must start to approach these things in a
professional and respectful manner.

The original D logo (and colours) must be used.

I'd say your zeal is a bit misdirected. "Professional" brands are
relaunched all the time. For a small sampling, check
http://blog.saijogeorge.com/big-brand-logo-redesign-success-failure-stories/.

David

Jul 01 2014
On Tuesday, 1 July 2014 at 08:34:30 UTC, Gary Willoughby wrote:
On Monday, 30 June 2014 at 21:23:59 UTC, David Gileadi wrote:
My opinion is that the redesign preserves the spirit of the
current logo while fitting in well with the flatter look. I
think someone who sees the one logo will recognize the other
in it (unlike some of the recent proposed logos).

On Tuesday, 1 July 2014 at 06:42:49 UTC, w0rp wrote:
The logo is a placeholder I made with no graphic design
experience. The old logo is a bit too fat and round to fit
with the new design, so I'd like something which is obviously
still the same brand, but looks a bit flatter.

No! You must use the original D logo, this is not up for
debate. I will fight this until the end. You cannot mess about
with the brand! We must start to approach these things in a
professional and respectful manner.

The original D logo (and colours) must be used.

The copyright of the original isn't owned by Walter. I think it'd
be best if we moved away from it. I like the flatter, cleaner
logo.

Jul 01 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 01/07/2014 6:08 PM, Brad Anderson wrote:
The original D logo (and colours) must be used.
The copyright of the original isn't owned by Walter. I think it'd be
best if we moved away from it. I like the flatter, cleaner logo.

Should anyone ever deem one of my designs worthy, I'd be happy to sign

A...

Jul 01 2014
"Dicebot" <public dicebot.lv> writes:
On Sunday, 29 June 2014 at 22:15:48 UTC, w0rp wrote:
I just finished translating all of the pages I have worked on
so far from diet templates to Markdown files. Now there is only
one diet layout loaded, and the rest is all Markdown files.
This has dramatically reduced the amount of memory consumed at
build time. You can see the results at the usual place at
http://w0rp.com:8010 and view the source on GitHub. I'll keep
at it and convert more pages from the main site.

the right side. Lack of this harms discoverability of existing
docs a lot.

Jul 01 2014
Shammah Chancellor <email domain.com> writes:
On 2014-06-29 22:15:47 +0000, w0rp said:

I just finished translating all of the pages I have worked on so far
from diet templates to Markdown files. Now there is only one diet
layout loaded, and the rest is all Markdown files. This has
dramatically reduced the amount of memory consumed at build time. You
can see the results at the usual place at http://w0rp.com:8010 and view
the source on GitHub. I'll keep at it and convert more pages from the
main site.

This looks awesome.  I like the new logo also.   Keep up the good work.

-Shammah

Jul 01 2014
On Tuesday, 1 July 2014 at 11:25:49 UTC, Shammah Chancellor wrote:
On 2014-06-29 22:15:47 +0000, w0rp said:

I just finished translating all of the pages I have worked on
so far from diet templates to Markdown files. Now there is
only one diet layout loaded, and the rest is all Markdown
files. This has dramatically reduced the amount of memory
consumed at build time. You can see the results at the usual
place at http://w0rp.com:8010 and view the source on GitHub.
I'll keep at it and convert more pages from the main site.

This looks awesome.  I like the new logo also.   Keep up the
good work.

-Shammah

It is not about liking it or not...

Jul 02 2014
"w0rp" <devw0rp gmail.com> writes:
I just brought the Twitter module back. I decided to run with
looking for '.sidebar.md' files as an easy way of dropping in
different sidebar content for particular pages, so the index uses
this now. I also brought the paragraph markers for the headings
back. That should bring Markdown stuff to a level where I can
drop in a bunch of pages now.

I put the logo my co-worker contributed in place there, which
looks a bit more familiar. I'll leave the logo like that for now.

Jul 02 2014
"Suliman" <evermind live.ru> writes:
I think it's better to remove mention about D1 on main page. It's
not actual and present time. But now it's took to many space...

Jul 02 2014
"Dicebot" <public dicebot.lv> writes:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.

:( it was so much better with this ugly widget gone and replaced
with something actually useful.

Jul 03 2014
"w0rp" <devw0rp gmail.com> writes:
On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.

:( it was so much better with this ugly widget gone and
replaced with something actually useful.

I actually didn't intend to remove it before, but if we want to
replace it with something else I could do that. I don't feel

Jul 03 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 03/07/2014 12:35 PM, w0rp wrote:
On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.

:( it was so much better with this ugly widget gone and replaced with
something actually useful.

I actually didn't intend to remove it before, but if we want to replace
it with something else I could do that. I don't feel strongly either way

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

A...

Jul 03 2014
"Dicebot" <public dicebot.lv> writes:
On Thursday, 3 July 2014 at 11:35:36 UTC, w0rp wrote:
On Thursday, 3 July 2014 at 09:42:05 UTC, Dicebot wrote:
On Wednesday, 2 July 2014 at 23:32:36 UTC, w0rp wrote:
I just brought the Twitter module back.

:( it was so much better with this ugly widget gone and
replaced with something actually useful.

I actually didn't intend to remove it before, but if we want to
replace it with something else I could do that. I don't feel

I'd prefer to see it removed but pretty sure many will be against
it. Even if we keep it as replacement for proper newsfeed, I'd
love to see it formatted the same way as main content and not as
side block widget (== no scrollbars, light background, no
repeating logos, no "follow" button etc)

Jul 03 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/10/14, 3:42 AM, SÃ¶nke Ludwig wrote:
* Are there any other opinions on this? I remember that there have been
some strong proponents of using DDOC for things, so it would be bad if
in the end Markdown were to be dropped, after all of the work has
already been done. Personally I'd strongly favor Markdown, though.

I think ddoc is a lot more flexible than markdown, and I'm baffled by
the claim that ddoc is difficult to learn. That said I do agree it's a
turnoff for first-time website contributors. IMHO if we switch away from
ddoc we should switch to something better, not something just different.
-- Andrei

Jun 10 2014
Jacob Carlborg <doob me.com> writes:
On 10/06/14 16:06, Andrei Alexandrescu wrote:

I think ddoc is a lot more flexible than markdown, and I'm baffled by
the claim that ddoc is difficult to learn. That said I do agree it's a
turnoff for first-time website contributors. IMHO if we switch away from
ddoc we should switch to something better, not something just different.

Something better/more powerful would be something backed by a proper
programming language.

--
/Jacob Carlborg

Jun 10 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 10.06.2014 16:06, schrieb Andrei Alexandrescu:
On 6/10/14, 3:42 AM, SÃ¶nke Ludwig wrote:
* Are there any other opinions on this? I remember that there have been
some strong proponents of using DDOC for things, so it would be bad if
in the end Markdown were to be dropped, after all of the work has
already been done. Personally I'd strongly favor Markdown, though.

I think ddoc is a lot more flexible than markdown, and I'm baffled by
the claim that ddoc is difficult to learn. That said I do agree it's a
turnoff for first-time website contributors. IMHO if we switch away from
ddoc we should switch to something better, not something just different.
-- Andrei

Markdown has the advantages of a semantic content representation - so
while it doesn't have a flexible macro system, external processors can
be used to transform it into any desired output format (including binary
or white space sensitive formats).

But the key points for me would be better readability and its broad
prevalence among the general developer community. One possibly major
consequence of this is tool support. For example, GitHub has a built-in
editor with preview for Markdown documents, so that anyone with a GitHub
account can quickly edit page contents without having to clone or build
the site.

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

<SeeWebsiteForEmail erdani.org> wrote:

On 6/10/14, 3:42 AM, S=C3=B6nke Ludwig wrote:
* Are there any other opinions on this? I remember that there have be=

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

f
in the end Markdown were to be dropped, after all of the work has
already been done. Personally I'd strongly favor Markdown, though.

I think ddoc is a lot more flexible than markdown, and I'm baffled by =

=

the claim that ddoc is difficult to learn. That said I do agree it's a=

=

turnoff for first-time website contributors. IMHO if we switch away fr=

om  =

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

t.

Markdown can be instantly understood by anyone who sees it. DDOC require=
s  =

lookup/learning, even if you know how DDOC works, you still have to figu=
re  =

out what all the macros mean and do. And none of that is documented as f=
ar  =

as I know.

Flexibility isn't everything. The goal is to make it easy to be an autho=
r.

-Steve

Jun 10 2014
"Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 June 2014 at 14:54:32 UTC, Steven Schveighoffer
wrote:
Markdown can be instantly understood by anyone who sees it.
DDOC requires lookup/learning, even if you know how DDOC works,
you still have to figure out what all the macros mean and do.
And none of that is documented as far as I know.

Flexibility isn't everything. The goal is to make it easy to be
an author.

This. I use DDOC for actual documentation daily and still was
reluctant to spend time on figuring out what all those macros
mean and how to use those. Better spend time on something both
interesting and useful.

Flexibility is hardly important at all here.

Jun 10 2014
Jacob Carlborg <doob me.com> writes:
On 10/06/14 10:12, SÃ¶nke Ludwig wrote:

But yes, it's definitely not what you want to have for D. I'm not sure
how much can be done about that, though - except from rewriting the CTFE
engine with performance in mind (maybe even using a JIT compiler). Or
maybe it's possible to be more liberal with algorithmic optimizations
when the CTFE memory usage brought to a reasonable level.

Can the templates be compiled in a separate phase, not using CTFE but as
a regular compiler?

--
/Jacob Carlborg

Jun 10 2014
"Puming" <zhaopuming gmail.com> writes:
On Tuesday, 10 June 2014 at 11:09:41 UTC, Jacob Carlborg wrote:
On 10/06/14 10:12, SÃ¶nke Ludwig wrote:

But yes, it's definitely not what you want to have for D. I'm
not sure
how much can be done about that, though - except from
rewriting the CTFE
engine with performance in mind (maybe even using a JIT
compiler). Or
maybe it's possible to be more liberal with algorithmic
optimizations
when the CTFE memory usage brought to a reasonable level.

Can the templates be compiled in a separate phase, not using
CTFE but as a regular compiler?

Or, just like ctRegx vs regx, can we have a runtime version of
diet template that runs slower but doesn't need to compile? It
would be great for development phase.

Jun 10 2014
"Dicebot" <public dicebot.lv> writes:
On Tuesday, 10 June 2014 at 11:35:32 UTC, Puming wrote:
On Tuesday, 10 June 2014 at 11:09:41 UTC, Jacob Carlborg wrote:
On 10/06/14 10:12, SÃ¶nke Ludwig wrote:

But yes, it's definitely not what you want to have for D. I'm
not sure
how much can be done about that, though - except from
rewriting the CTFE
engine with performance in mind (maybe even using a JIT
compiler). Or
maybe it's possible to be more liberal with algorithmic
optimizations
when the CTFE memory usage brought to a reasonable level.

Can the templates be compiled in a separate phase, not using
CTFE but as a regular compiler?

Or, just like ctRegx vs regx, can we have a runtime version of
diet template that runs slower but doesn't need to compile? It
would be great for development phase.

We can't because Diet templates may contain arbitrary D code
inline.

Jun 10 2014
Jacob Carlborg <doob me.com> writes:
On 31/05/14 21:49, w0rp wrote:
After watching Andrei's keynote where he was asking for help, and
noticing that there wasn't any proof of someone working on this, I took
charge.

http://w0rp.com:8010/

I kind of like it. It would be nice to see examples of a couple of other
pages as well. The menus are removed when the width of the page gets too
small. I assume they're supposed to become a collapsed drop down menu
like this: http://getbootstrap.com/examples/starter-template/

That's the design in the form of a single page website running on my
Linode. The source is available here.

https://github.com/w0rp/new-dlang.org

I would like to keep going with this and just redesign the whole
website. A few points worth noting.

* This is entirely a vibe.d website. (See the source.)
* For pages, DDoc is replaced with diet templates.

Yes, thank you, finally.

Those seconds in between making a change and seeing the results really
build up over time. It's probably hard to describe without trying it
yourself, but trust me, it matters. This is the kind of thing I have
recently fought against at work, and it was well worth it. I replaced a
Compass filesystem monitor with an even slightly broken libsass CPython
compiler which compiled SCSS based on modification times. The couple
seconds of difference has definitely improved the day-to-day life of
myself and the web designer I work with.

Try that with livereload as well. For CSS it doesn't need to reload the
whole page, it just inserts the new CSS.

--
/Jacob Carlborg

Jun 02 2014
"w0rp" <devw0rp gmail.com> writes:
On Monday, 2 June 2014 at 12:28:53 UTC, Jacob Carlborg wrote:
I kind of like it. It would be nice to see examples of a couple
of other pages as well. The menus are removed when the width of
the page gets too small. I assume they're supposed to become a
collapsed drop down menu like this:
http://getbootstrap.com/examples/starter-template/

Yes, I plan to follow the usual pattern for having a drop down
menu for small screens, I just haven't impelemented it yet.
(Bootstrap should make this easy.)

...

Try that with livereload as well. For CSS it doesn't need to
reload the whole page, it just inserts the new CSS.

I don't need to recompile when I make CSS changes thankfully, but
a lot of experimenting with page layout means rapidly changing
page content, so that means changing HTML. The problem isn't too
severe, but the cycle could be made a bit tighter with automatic
recompilation of diet templates, which SÃ¶nke says is possible
with about a week of work or so. (SÃ¶nke is *the man* and has
addressed a lot of my concerns in a timely manner in the past.)

Jun 02 2014
"Dicebot" <public dicebot.lv> writes:
On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:
After watching Andrei's keynote where he was asking for help,
and noticing that there wasn't any proof of someone working on
this, I took charge.

http://w0rp.com:8010/

Looks good! Can twitter widget be forced to rescale on wider
screens? It looks very annoying right now with scroll-bar and lot
of line breaks when half of the space is still available.

* For pages, DDoc is replaced with diet templates.

If this will happen, I will actually start to contribute to
documentation :)

Jun 02 2014
Jacob Carlborg <doob me.com> writes:
On 2014-06-02 16:45, Dicebot wrote:

If this will happen, I will actually start to contribute to
documentation :)

Agree. This would also make a reason for me to learn vibe.d.

--
/Jacob Carlborg

Jun 02 2014
"Uranuz" <neuranuz gmail.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
Hello,

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

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

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

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

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

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

So, what do you guys think?

-- Aleksandar

Looks pretty well. What I don't like is dark background for
section of code. I prefer reading text on light background. But
tastes differ! For example OS console on Windows or Linux is
usually has dark background.

Jul 01 2014
"Chris" <wendlec tcd.ie> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
Hello,

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

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

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

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

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

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

So, what do you guys think?

-- Aleksandar

design, it's a good starting point. Especially the integration of
the logo. Nice and clean. (The current logo is just too bulky and
clumsy, imo*)

However, my experience tells me that we should wait with
redesigning it until the technical issues/problems have been
solved, e.g. the migration to vibe.d, which I'm in favor of (I've
had good experiences with vibe.d so far), and the doc generation
issue etc etc. Once that is out of the way, we can think about
new designs. Yours is very nice and "modern". However, we also
have to take mobile devices (tablets, smartphones) into account
and see how we can adapt to these (different layouts or one for
all?).

Another issue is that we don't have to jump on any bandwagon
(every time the "fashion" changes), we can roll our own design,
one that fits the community's and the language's needs,
regardless of what is trendy or "modern" at any given time (don't
imitate, innovate!).

My two cents anyway ...

*(D is already a bulky letter, so there shouldn't be much else on
the logo)

Jul 03 2014
"w0rp" <devw0rp gmail.com> writes:
On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:
the design, it's a good starting point. Especially the
integration of the logo. Nice and clean. (The current logo is
just too bulky and clumsy, imo*)

However, my experience tells me that we should wait with
redesigning it until the technical issues/problems have been
solved, e.g. the migration to vibe.d, which I'm in favor of
(I've had good experiences with vibe.d so far), and the doc
generation issue etc etc. Once that is out of the way, we can

I've been focusing on getting a working site with vibe.d.
Integrating the ddox document generator is a high priority for me
right now, especially since I've finished a lot of work for
formatting the changelog pages.

Yours is very nice and "modern". However, we also have to take
mobile devices (tablets, smartphones) into account and see how
we can adapt to these (different layouts or one for all?).

I used the Bootstrap framework, which I have also used in my day
job. Bootstrap makes producing a responsive design pretty easy.
I've been periodically testing pages on smaller screens.
Firefox's 'reponsive design mode' helps a lot with this.

Another issue is that we don't have to jump on any bandwagon
(every time the "fashion" changes), we can roll our own design,
one that fits the community's and the language's needs,
regardless of what is trendy or "modern" at any given time
(don't imitate, innovate!).

There are many different designs you could produce. Many design
choices are subjective, though not all of them. I think my goals
for the work I've been doing are as follows.

* Improve display across different devices.
* Improve the quality of text to make it easier to read.
* Make it easier for newcomers to edit, to encourage contribution.
* Run it all with D to tick a "official D site made in D"
checkbox.

There are others, but those are the important ones.

Jul 03 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 03/07/2014 6:38 PM, w0rp wrote:

* Run it all with D to tick a "official D site made in D" checkbox.

In a nod to Walter's self confessed petrol-headedness, I thought we
could incorporate the logo into a "D under the hood" or "D in the tank"
banner for sites and software that utilise or run on D.

Might be a bit over the top for dlang.org though ^^

A...

Jul 03 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 Jul 2014 20:45, "Alix Pexton via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On 03/07/2014 6:38 PM, w0rp wrote:

* Run it all with D to tick a "official D site made in D" checkbox.

In a nod to Walter's self confessed petrol-headedness, I thought we could

incorporate the logo into a "D under the hood" or "D in the tank" banner
for sites and software that utilise or run on D.
Might be a bit over the top for dlang.org though ^^

A...


Jul 03 2014
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
[â€¦]

SarcasticRover is telling us "Do not come to Mars." Perhaps its
commentary need censoring ;-)

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

Jul 04 2014
On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via
Digitalmars-d wrote:
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via
Digitalmars-d wrote:
[â€¦]

SarcasticRover is telling us "Do not come to Mars." Perhaps its
commentary need censoring ;-)

He also get angry when you mention that using the imperial system
is idiotic.

Jul 08 2014
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 8 July 2014 21:20, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via

Digitalmars-d wrote:
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
[â€¦]

SarcasticRover is telling us "Do not come to Mars." Perhaps its
commentary need censoring ;-)

He also get angry when you mention that using the imperial system
is idiotic.

But the imperial system *isn't* idiotic. :o)

And everyone should drive on the left.

Jul 08 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 08/07/2014 10:01 PM, Iain Buclaw via Digitalmars-d wrote:
But the imperial system *isn't* idiotic. :o)

14 lbs is a stone? apart from that its fine ^^

And everyone should drive on the left.

I drive in the middle, it works fine until I meet other road users.

A...

Jul 08 2014
"Chris" <wendlec tcd.ie> writes:
On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 8 July 2014 21:20, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via

Digitalmars-d wrote:
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via
Digitalmars-d wrote:
[â€¦]

SarcasticRover is telling us "Do not come to Mars." Perhaps
its
commentary need censoring ;-)

He also get angry when you mention that using the imperial
system
is idiotic.

But the imperial system *isn't* idiotic. :o)

And everyone should drive on the left.

Driving on the left goes back to the times when coaches
(carriages) were still in use. This was to avoid that drivers
would accidentally hit each other with their whips when a coach
would come from the opposite direction. No joke. As regards cars,
driving on the left is highly unintuitive for most people as the
majority of drivers are right-handed. There is no ergonomic or
technical reason why cars should drive on the left. In most parts
of the world driving on the right was adopted from early on as it
is more intuitive (for most people).

Jul 09 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 09/07/2014 12:36 PM, Chris wrote:
On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via Digitalmars-d

And everyone should drive on the left.

Driving on the left goes back to the times when coaches (carriages) were
still in use. This was to avoid that drivers would accidentally hit each
other with their whips when a coach would come from the opposite
direction. No joke. As regards cars, driving on the left is highly
unintuitive for most people as the majority of drivers are right-handed.
There is no ergonomic or technical reason why cars should drive on the
left. In most parts of the world driving on the right was adopted from
early on as it is more intuitive (for most people).

Driving on the left actually originates from jousting. On a tilting yard
each combatant rides on the right side and aims their lance across their
body at the opponent in the lane on the left. When knights passed each
other out on the roads, the would do so on the left side so show that
they were not hostile. The whole of Europe took up this practice, and
used to always ride, drive carts and march as a body of men on the left.

Then a chap called Napoleon came along and used a guerilla tactic to
trick his enemy by marching on the right so that his troops looked like
they were travelling in the opposite direction. Eventually driving on
the wrong side became the norm for all the regions of Europe that
Napoleon conquered, and it spread as a matter of practicality to
adjacent regions over time. Napoleon was defeated by the English because
this trick does not work at sea. The UK still drives on the correct side
because there is no problem with having to swap sides when crossing land
borders. It is also an act that commemorates that historic victory.

Or at least that is what I learned in school ^^

A...

Jul 09 2014
"Chris" <wendlec tcd.ie> writes:
On Wednesday, 9 July 2014 at 15:34:03 UTC, Alix Pexton wrote:
On 09/07/2014 12:36 PM, Chris wrote:
On Tuesday, 8 July 2014 at 21:01:46 UTC, Iain Buclaw via
Digitalmars-d

And everyone should drive on the left.

Driving on the left goes back to the times when coaches
(carriages) were
still in use. This was to avoid that drivers would
accidentally hit each
other with their whips when a coach would come from the
opposite
direction. No joke. As regards cars, driving on the left is
highly
unintuitive for most people as the majority of drivers are
right-handed.
There is no ergonomic or technical reason why cars should
drive on the
left. In most parts of the world driving on the right was
early on as it is more intuitive (for most people).

Driving on the left actually originates from jousting. On a
tilting yard each combatant rides on the right side and aims
their lance across their body at the opponent in the lane on
the left. When knights passed each other out on the roads, the
would do so on the left side so show that they were not
hostile. The whole of Europe took up this practice, and used to
always ride, drive carts and march as a body of men on the left.

Then a chap called Napoleon came along and used a guerilla
tactic to trick his enemy by marching on the right so that his
troops looked like they were travelling in the opposite
direction. Eventually driving on the wrong side became the norm
for all the regions of Europe that Napoleon conquered, and it
time. Napoleon was defeated by the English because this trick
does not work at sea. The UK still drives on the correct side
because there is no problem with having to swap sides when
crossing land borders. It is also an act that commemorates that
historic victory.

Or at least that is what I learned in school ^^

A...

This sounds just like Imperial education. Very interesting how it
equates Imperial practices with the "right" thing and the
(continental) arch enemy with the "wrong" thing. By the way,
there was a reason why combatant riders would ride on the right
side on a tilting yard: they were right-handed. Just as it makes
more sense to switch gears with the right hand and not with the
(in most cases) weaker left hand.

Jul 09 2014
Alix Pexton <alix.DOT.pexton gmail.DOT.com> writes:
On 09/07/2014 4:43 PM, Chris wrote:
This sounds just like Imperial education. Very interesting how it
equates Imperial practices with the "right" thing and the (continental)
arch enemy with the "wrong" thing. By the way, there was a reason why
combatant riders would ride on the right side on a tilting yard: they
were right-handed. Just as it makes more sense to switch gears with the
right hand and not with the (in most cases) weaker left hand.

Sorry, the correct side/wrong side designations was all me, I have
trouble with light and reft, and didn't want to get mixed up with the 2
meanings of right. Perhaps its an artefact of my imperial education ^^

Also some argue that it makes more sense in a modern car to change gear
with the left hand and keep the stronger arm on the steering wheel.
Early right-hand-drive cars either had all foot operated gears, or they
were on the outside (actually outside the cockpit) rather than in the
middle because they needed real effort, modern gears especially
automatics don't need that effort any more.

A...

Jul 09 2014
"Chris" <wendlec tcd.ie> writes:
On Wednesday, 9 July 2014 at 21:20:28 UTC, Alix Pexton wrote:
On 09/07/2014 4:43 PM, Chris wrote:
This sounds just like Imperial education. Very interesting how
it
equates Imperial practices with the "right" thing and the
(continental)
arch enemy with the "wrong" thing. By the way, there was a
reason why
combatant riders would ride on the right side on a tilting
yard: they
were right-handed. Just as it makes more sense to switch gears
with the
right hand and not with the (in most cases) weaker left hand.

Sorry, the correct side/wrong side designations was all me, I
have trouble with light and reft, and didn't want to get mixed
up with the 2 meanings of right. Perhaps its an artefact of my
imperial education ^^

I see. Your account of what you learned is interesting
nevertheless, because it implies that the Empire kept the ancient
system, whereas now a new "corrupt" system is used in the rest of
the world, a system that has its roots in the "insidious" tactics
of a Frenchman called Napoleon.

Also some argue that it makes more sense in a modern car to
change gear with the left hand and keep the stronger arm on the
steering wheel. Early right-hand-drive cars either had all foot
operated gears, or they were on the outside (actually outside
the cockpit) rather than in the middle because they needed real
effort, modern gears especially automatics don't need that
effort any more.

A...

I don't agree. A lot of cars still use manual gears, not
automatics. I also find that in dangerous situations it is better
that the stronger arm has more room for action in the cockpit and
is not impeded by the window / door. Also, pressing buttons on
the radio / audio player, air conditioning etc. is much easier
(=precise) with the stronger arm, especially while driving when
these actions cannot get your undivided attention. This is at
least my experience, but many people have agreed with me on this.

Jul 10 2014
"w0rp" <devw0rp gmail.com> writes:
http://w0rp.com:8010/library/index.html

I just updated the site hosted there with the work I've done on
integrating the library documentation to date. I spent a lot of
time staring at the pages for a while trying to figure out how to
fit everything on a page decent. I admit to hacking the
std.algoritm tables into not being tables, etc. I would very much
appreciate any pull requests which improve on what I've done so
far with it. It's all on GitHub in the usual place.

https://github.com/w0rp/new-dlang.org

Right now I'm using some of the layouts modified from SÃ¶nke's
ddox templates, some modified from the dlang.org stuff. I'm using
Adam D. Ruppe's DOM library, etc. I would like to properly
attribute everyone for everything, so I would really appreciate
input on where to credit people if I missed anything out. I have
a COPYRIGHT file I can add people to if needed for that purpose,

I still haven't included syntax highlighting. This really isn't
hard, I just haven't gotten around to doing it yet.

There's still a lot of work to be done, but it's one step closer
now.

Jul 26 2014
"Dicebot" <public dicebot.lv> writes:
..and fixed width docs again. Unfortunately I am not competent
enough to propose any change so user CSS it stays for me :(

All pages seem to miss all examples - simply not implemented yet
or oversight?

Jul 26 2014
"Dicebot" <public dicebot.lv> writes:
On Sunday, 27 July 2014 at 00:38:14 UTC, Dicebot wrote:
All pages seem to miss all examples - simply not implemented
yet or oversight?

ah, nevermind:

I still haven't included syntax highlighting. This really isn't
hard, I just haven't gotten around to doing it yet.


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

I just updated the site hosted there with the work I've done on
integrating the library documentation to date. I spent a lot of time
staring at the pages for a while trying to figure out how to fit
everything on a page decent. I admit to hacking the std.algoritm
tables into not being tables, etc. I would very much appreciate any
pull requests which improve on what I've done so far with it. It's all
on GitHub in the usual place.

What do you think about using tables for the functions under each
category (e.g. under "searching" in std.algorithm)? Currently it looks
like a random scattering of words, and it's quite confusing to look for
a particular symbol. A left-justified multi-column layout would be much
better IMHO.

https://github.com/w0rp/new-dlang.org

[...]

I'll keep that in mind for when I have a bit more time; currently I'm
rather swamped and probably won't have time to submit PRs.

T

--
Computers aren't intelligent; they only think they are.

Jul 26 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 27 July 2014 at 00:43:41 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sat, Jul 26, 2014 at 10:54:12PM +0000, w0rp via
Digitalmars-d wrote:
http://w0rp.com:8010/library/index.html

I just updated the site hosted there with the work I've done on
integrating the library documentation to date. I spent a lot
of time
staring at the pages for a while trying to figure out how to
fit
everything on a page decent. I admit to hacking the
std.algoritm
tables into not being tables, etc. I would very much
appreciate any
pull requests which improve on what I've done so far with it.
It's all
on GitHub in the usual place.

What do you think about using tables for the functions under
each
category (e.g. under "searching" in std.algorithm)? Currently
it looks
like a random scattering of words, and it's quite confusing to
look for
a particular symbol. A left-justified multi-column layout would
be much
better IMHO.

The std.algortihm documentation doesn't look good, and I don't
have any good ideas for it.

Jul 26 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/26/14, 6:30 PM, w0rp wrote:
The std.algortihm documentation doesn't look good, and I don't have any
good ideas for it.

I find std.algorithm among the best documented libraries out there! I
must be in denial... -- Andrei

Jul 26 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/26/14, 6:30 PM, w0rp wrote:
The std.algortihm documentation doesn't look good, and I don't have
any good ideas for it.

I find std.algorithm among the best documented libraries out there! I
must be in denial... -- Andrei

"No, I'm not in denial! It can't be!!!"

:-P

--
Ð–Ð¸Ð²Ñ‘ÑˆÑŒ Ñ‚Ð¾Ð»ÑŒÐºÐ¾ Ð¾Ð´Ð½Ð°Ð¶Ð´Ñ‹.

Jul 26 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/26/14, 8:47 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu via
Digitalmars-d wrote:
On 7/26/14, 6:30 PM, w0rp wrote:
The std.algortihm documentation doesn't look good, and I don't have
any good ideas for it.

I find std.algorithm among the best documented libraries out there! I
must be in denial... -- Andrei

"No, I'm not in denial! It can't be!!!"

Well correction: I think it's among the better documented modules in
std. -- Andrei

Jul 26 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 27 July 2014 at 06:10:09 UTC, Andrei Alexandrescu
wrote:
On 7/26/14, 8:47 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 7/26/14, 6:30 PM, w0rp wrote:
The std.algortihm documentation doesn't look good, and I
don't have
any good ideas for it.

I find std.algorithm among the best documented libraries out
there! I
must be in denial... -- Andrei

"No, I'm not in denial! It can't be!!!"

Well correction: I think it's among the better documented
modules in std. -- Andrei

It's not the text, it's just the current formatting. The cheat
sheet can't fit into a smaller column size as a table. So you can
it will reflow, but then the length of the page gets bumped up
quite a bit and makes it harder to find things at a glance.

Because it's probably the most important library in all of
Phobos, it's probably worth excluding the usual output of lists
of Functions, Structs, etc. from std.algortihm and letting the
cheat sheet itself be the list of symbols, which is organised a
lot better than a sort by symbol type then name will ever be. I
like the "these are for iteration" kind of categorisation. I'd
probably then remove the table right at the top, so you have the
module description and example above the fold.

That's what I'm thinking at the moment anyway.

Jul 27 2014
On Sunday, 27 July 2014 at 13:30:18 UTC, w0rp wrote:
It's not the text, it's just the current formatting. The cheat
sheet can't fit into a smaller column size as a table. So you
can break that down into smaller headings and paragraphs
instead so it will reflow, but then the length of the page gets
bumped up quite a bit and makes it harder to find things at a
glance.

Because it's probably the most important library in all of
Phobos, it's probably worth excluding the usual output of lists
of Functions, Structs, etc. from std.algortihm and letting the
cheat sheet itself be the list of symbols, which is organised a
lot better than a sort by symbol type then name will ever be. I
like the "these are for iteration" kind of categorisation. I'd
probably then remove the table right at the top, so you have
the module description and example above the fold.

That's what I'm thinking at the moment anyway.

This is completely the wrong way to design anything. The design
needs rework if it can't handle the content. You don't shorten
the content to fit your design!

Also the main content area is far too narrow. The current design
look ridiculous on a large monitor.

Desktop: http://imgur.com/Xr25TJ8

and because the design is fixed and not responsive in *any* way
it also looks dire on mobile devices.

iPhone: http://imgur.com/fHduaH7

This is a poor amateurish design and i wish you would stop right
now. If this ever goes live not only will all developers be
extremely frustrated trying to actually read the documentation
but we as a community are going to be laughing stock of the
programming world!

This needs the attention of a professional designer and web
developer.

Jul 27 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.07.2014 16:55, schrieb Gary Willoughby:
This is a poor amateurish design and i wish you would stop right now. If
this ever goes live not only will all developers be extremely frustrated
trying to actually read the documentation but we as a community are
going to be laughing stock of the programming world!

This needs the attention of a professional designer and web developer.

I really wish you'd stop with this destructive attitude. Yes, the web
design part is not ready for prime time, but it's definitely a big step
forward already in many aspects, IMO.

Why don't you contribute some concrete CSS improvements, alternative
design drafts, or at least suggestions instead of continuously trying to
choke off all efforts? After all, the whole project is a community
effort and I'm pretty sure that w0rp would happily accept some support.

Another thing is that most of the things done so far, as far as I
understand, haven't been about the design or implementation thereof, but

Jul 27 2014
On Sunday, 27 July 2014 at 16:59:15 UTC, SÃ¶nke Ludwig wrote:
I really wish you'd stop with this destructive attitude. Yes,
the web design part is not ready for prime time, but it's
definitely a big step forward already in many aspects, IMO.

Since when is the truth destructive?

Jul 28 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.07.2014 09:18, schrieb Gary Willoughby:
On Sunday, 27 July 2014 at 16:59:15 UTC, SÃ¶nke Ludwig wrote:
I really wish you'd stop with this destructive attitude. Yes, the web
design part is not ready for prime time, but it's definitely a big
step forward already in many aspects, IMO.

Since when is the truth destructive?

"completely the wrong way to design anything.", "current design look
ridiculous", "poor amateurish design", "i wish you would stop right now"
- all of those comments look pretty destructive to me. Truth or not
doesn't have to have anything to do with being destructive or
constructive. Most of the time there is a good truth and a bad truth and
just focusing on the bad side can be pretty destructive.

What I'd wish for would be something like s/i wish you would stop right
now/i'd suggest to .../g - or maybe pledge for a professional web
designer? Just something that brings us forward instead of just
promoting stagnancy.

Jul 28 2014
On Monday, 28 July 2014 at 10:38:12 UTC, SÃ¶nke Ludwig wrote:
"completely the wrong way to design anything.", "current design
look ridiculous", "poor amateurish design", "i wish you would
stop right now" - all of those comments look pretty destructive
to me.

No, that's the truth! You can sugar coat it all you want but at
the end of the day you have to be blunt and honest if you want
professional results.

I did in fact start conversing with w0rp in a more congenial
manner but his childish attitude was when i decided to stop
pulling punches. My first comment was to suggest some javascript
libraries which was ignored. Then i pleaded with w0rp to use the
correct logo and colors. Which was then dismissed as he thought
*his* logo was better than the official one.

See the first reply in this post in which i outlined my position:

and tell me again who is being destructive. In that same thread
Walter is quoted as saying: "All excellent points, and I agree
with you on all of them. And I like the current logo, and want to
keep it." and yet w0rp still insists on going forward with this
terrible design.

Truth or not doesn't have to have anything to do with being
destructive or constructive. Most of the time there is a good
truth and a bad truth and just focusing on the bad side can be
pretty destructive.

You're joking right? Anyone can see it's terrible and needs to be
done better. There are no versions of truth!

What I'd wish for would be something like s/i wish you would
stop right now/i'd suggest to .../g - or maybe pledge for a
professional web designer? Just something that brings us
forward instead of just promoting stagnancy.

I tried but was immediately dismissed.

Jul 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 10:25 AM, Gary Willoughby wrote:
On Monday, 28 July 2014 at 10:38:12 UTC, SÃ¶nke Ludwig wrote:
"completely the wrong way to design anything.", "current design look
ridiculous", "poor amateurish design", "i wish you would stop right
now" - all of those comments look pretty destructive to me.

No, that's the truth! You can sugar coat it all you want but at
the end of the day you have to be blunt and honest if you want
professional results.

No, if you want professional results you have to do professional work.

Andrei

Jul 28 2014
On Monday, 28 July 2014 at 18:13:50 UTC, Andrei Alexandrescu
wrote:
On 7/28/14, 10:25 AM, Gary Willoughby wrote:
On Monday, 28 July 2014 at 10:38:12 UTC, SÃ¶nke Ludwig wrote:
"completely the wrong way to design anything.", "current
design look
ridiculous", "poor amateurish design", "i wish you would stop
right
now" - all of those comments look pretty destructive to me.

No, that's the truth! You can sugar coat it all you want but at
the end of the day you have to be blunt and honest if you want
professional results.

No, if you want professional results you have to do
professional work.

Andrei

Of course, but you have to be honest when things are not going
well!

On Monday, 28 July 2014 at 18:51:45 UTC, SÃ¶nke Ludwig wrote:
Also, and this needs to be stressed, the major part of w0rp's
work so far is about the technical basis. You dismissed that as
a minor detail, but it is not.

The design is *the* most important part of the web site. Period!
No one cares how it works, only the user experience of the site
matters. Do you think users give a hoot how facebook works?

Yes someone does have to do the 'technical stuff' behind the
scenes. I do it on a daily basis but users don't care about the
backend. Even if the case was made that *this* site is for
engineers, the design will do. Well, systems engineers are
sticking with C/C++ and app devs are sticking with Java/C# so we
must make this site as accessible for everyone. We need to 'sell'
D, not make it look amateurish.

In andreis Quo vadis talk i found it inspiring that he said in
order to be considered a player we need to start acting like a
player (paraphrasing). We need to start upping our game at this
stuff!

The whole reason for this site's existence is to 'sell' D as much
as possible _including_ being used as a repository of knowledge.
It will sell better if the design is good, easy on the eye and
easy to find what you need. The w0rp design is none of those,
stop pretending it is.

Also who starts a project without designing it first? I mean
honestly, why start such a major piece of work without even a
vague spec? Has w0rp even asked users here what the site needs to
encompass? Has the question been asked what content must exist,
who needs what info and where, colour schemes, for mobile
devices?  etc.


Jul 28 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.07.2014 21:13, schrieb Gary Willoughby:
On Monday, 28 July 2014 at 18:51:45 UTC, SÃ¶nke Ludwig wrote:
Also, and this needs to be stressed, the major part of w0rp's work so
far is about the technical basis. You dismissed that as a minor
detail, but it is not.

The design is *the* most important part of the web site. Period! No one
cares how it works, only the user experience of the site matters. Do you
think users give a hoot how facebook works?

Yes, I don't try to argue against the importance of the design. The
point is that it's an orthogonal feature and that it can be worked on
mostly independently. You focus on the design and w0rp mostly focuses on
the technical side, which is probably part of the reason why the
discussion doesn't work out very well.

Also who starts a project without designing it first? I mean honestly,
why start such a major piece of work without even a vague spec? Has w0rp
even asked users here what the site needs to encompass? Has the question
been asked what content must exist, who needs what info and where,
colour schemes, for mobile devices?  etc.

He basically just took the mockup of Aleksandar Ruzicic, which was met
with some optimism, and brought it to live. AFAICS that's all he really
did WRT the design. The content was basically meant to stay the same as
it is now*.

* Honestly, apart from some important key parts, such as the front page
or the download page, it would be insane to start over and redo the
contents, just for the sheer amount of work that this would mean.

Jul 28 2014
"w0rp" <devw0rp gmail.com> writes:
On Monday, 28 July 2014 at 19:31:24 UTC, SÃ¶nke Ludwig wrote:
Am 28.07.2014 21:13, schrieb Gary Willoughby:
On Monday, 28 July 2014 at 18:51:45 UTC, SÃ¶nke Ludwig wrote:
Also, and this needs to be stressed, the major part of w0rp's
work so
far is about the technical basis. You dismissed that as a
minor
detail, but it is not.

The design is *the* most important part of the web site.
Period! No one
cares how it works, only the user experience of the site
matters. Do you
think users give a hoot how facebook works?

Yes, I don't try to argue against the importance of the design.
The point is that it's an orthogonal feature and that it can be
worked on mostly independently. You focus on the design and
w0rp mostly focuses on the technical side, which is probably
part of the reason why the discussion doesn't work out very
well.

Also who starts a project without designing it first? I mean
honestly,
why start such a major piece of work without even a vague
spec? Has w0rp
even asked users here what the site needs to encompass? Has
the question
been asked what content must exist, who needs what info and
where,
colour schemes, for mobile devices?  etc.

He basically just took the mockup of Aleksandar Ruzicic, which
was met with some optimism, and brought it to live. AFAICS
that's all he really did WRT the design. The content was
basically meant to stay the same as it is now*.

* Honestly, apart from some important key parts, such as the
front page or the download page, it would be insane to start
over and redo the contents, just for the sheer amount of work
that this would mean.

I'm not a designer. I'm a web developer. My understanding of web
design only comes from a technical and UX point of view. How CSS
works, how to structure forms to make them easier to read, etc. I
would love to get some help from a designer. It is as you say. I
brought Aleksandar's design to life, and that's pretty much how I
work during the day. I work with designers who provide mock-ups,
maybe some CSS, and I make it work.

I respect Gary's opinion that you should work on design first
then the technical aspects, but I believe you can work either
way, probably both ways simultaneously, and achieve the same
result. Architecture and design cannot function without one
another. Because I have far more experience as a web developer,
I've put the vast majority of my focus on putting the site
together so all of the pages fit into place, because they aren't
going to change a great deal from how they are now in terms of
content.

When it comes to web design, I just fill in the blanks when
there's no-one else to help. It's amateur work because I'm not
trained as a designer. So I'm just working on what I know I can
eventually get right until someone with more design experience
who is willing to submit pull requests comes along.

Jul 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 12:13 PM, Gary Willoughby wrote:
On Monday, 28 July 2014 at 18:13:50 UTC, Andrei Alexandrescu wrote:
On 7/28/14, 10:25 AM, Gary Willoughby wrote:
On Monday, 28 July 2014 at 10:38:12 UTC, SÃ¶nke Ludwig wrote:
"completely the wrong way to design anything.", "current design look
ridiculous", "poor amateurish design", "i wish you would stop right
now" - all of those comments look pretty destructive to me.

No, that's the truth! You can sugar coat it all you want but at
the end of the day you have to be blunt and honest if you want
professional results.

No, if you want professional results you have to do professional work.

Andrei

Of course, but you have to be honest when things are not going well!

Being honest does not entail being a jerk. -- Andrei

(edited)

Jul 28 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 28 July 2014 at 19:13:12 UTC, Gary Willoughby wrote:
Also who starts a project without designing it first? I mean
honestly, why start such a major piece of work without even a
vague spec? Has w0rp even asked users here what the site needs
to encompass? Has the question been asked what content must
exist, who needs what info and where, colour schemes, for
mobile devices?  etc.

Current web site has certain purely technical issues that
switching to more dynamic vibe.d based implementation will help
to deal with. Even if design doesn't change a single bit it is a
welcome and much needed change. Because of that starting with
technical stuff makes perfect sense.

Stuff you care about is marketing stuff. It is only partially
relevant to informational usability concerns that are of primary
interest to existing language users.

Jul 29 2014
"Kagamin" <spam here.lot> writes:
On Monday, 28 July 2014 at 19:13:12 UTC, Gary Willoughby wrote:
Do you think users give a hoot how facebook works?

I've seen an expressed concern here (probably by Nick) about
facebook using PHP, the latter being a not so good language. In a
reddit announcement about dlang forum there was a discussion
about whether it's fast because the backend is compiled to native
code or because the frontend is optimized.

We need to 'sell' D, not make it look amateurish.

Yes, but a good LAMP design sells LAMP instead of D.

Jul 29 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 28.07.2014 19:25, schrieb Gary Willoughby:
On Monday, 28 July 2014 at 10:38:12 UTC, SÃ¶nke Ludwig wrote:
"completely the wrong way to design anything.", "current design look
ridiculous", "poor amateurish design", "i wish you would stop right
now" - all of those comments look pretty destructive to me.

No, that's the truth! You can sugar coat it all you want but at
the end of the day you have to be blunt and honest if you want
professional results.

That may be the case in a professional setting where everyone is payed
to do the work. But in a community of volunteers this probably just

I did in fact start conversing with w0rp in a more congenial
manner but his childish attitude was when i decided to stop
pulling punches. My first comment was to suggest some javascript
libraries which was ignored. Then i pleaded with w0rp to use the
correct logo and colors. Which was then dismissed as he thought
*his* logo was better than the official one.

My perception was that he stated that his logo was just a placeholder
and that someone would still have to get it right. The colors, as far as
I can see, match the original logo pretty well, even though there are
less highlights.

See the first reply in this post in which i outlined my position:

and tell me again who is being destructive. In that same thread
Walter is quoted as saying: "All excellent points, and I agree
with you on all of them. And I like the current logo, and want to
keep it." and yet w0rp still insists on going forward with this
terrible design.

There have been quite some different opinions on the logo topic, and
personally I think that removing the "button" border is absolutely fine,
while shape and color are important not to alter without very good
reason. My understanding was that w0rp was basically intending to just
flattening the logo, although I see that changing the shape has also
been part of the discussion. My perception also was that Walter
understood that the logo was to be completely changed instead of just
flattened, but I may be completely wrong, of course.

Anyway what's far worse is that the licensing situation of the current
logo isn't clear and worst case it could mean that we'd have to switch
the logo. But sorry, this is getting off topic.

Truth or not doesn't have to have anything to do with being
destructive or constructive. Most of the time there is a good truth
and a bad truth and just focusing on the bad side can be pretty
destructive.

You're joking right? Anyone can see it's terrible and needs to be
done better. There are no versions of truth!

I'm not joking. There are some substantial improvements regarding the
global page navigation. The planned search feature would also be a big
improvement. The rest of the page is currently modeled after the mockup
that got posted by the OP and really hasn't been subject to any deeper
thoughts so far.

This is what I mean with the positive truth, and what just bothered me
is when you started to completely dismiss the whole project as bad. I
just don't like talking in purely black and white, because reality
almost never is.

Also, and this needs to be stressed, the major part of w0rp's work so
far is about the technical basis. You dismissed that as a minor detail,
but it is not. It's a part of the whole thing that also needs to get
done and someone has to do it. The good thing is that it is - with the
help of good semantic HTML and good use of CSS - mostly independent of
the site layout and styling.

What I'd wish for would be something like s/i wish you would stop
right now/i'd suggest to .../g - or maybe pledge for a professional
web designer? Just something that brings us forward instead of just
promoting stagnancy.

I tried but was immediately dismissed.

I think that the discussion just too quickly went into an all or nothing
argument, which is always difficult to resolve. And I guess this was
also at least part of the reason why you stopped with suggestions and
why w0rp possibly has troubles accepting valid criticism from you...

Anyway, what about making some quick mockups or design rules that could
be used as a basis for a more principled approach? But I have to admit
that this forum is not the ideal place to work on something like this.
We need a much more structured approach to answer questions such as the
ones Ola posted. Maybe using a separate newsgroup or mailing list + the
wiki.

Jul 28 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 27 July 2014 at 14:55:59 UTC, Gary Willoughby wrote:
On Sunday, 27 July 2014 at 13:30:18 UTC, w0rp wrote:
It's not the text, it's just the current formatting. The cheat
sheet can't fit into a smaller column size as a table. So you
can break that down into smaller headings and paragraphs
instead so it will reflow, but then the length of the page
gets bumped up quite a bit and makes it harder to find things
at a glance.

Because it's probably the most important library in all of
Phobos, it's probably worth excluding the usual output of
lists of Functions, Structs, etc. from std.algortihm and
letting the cheat sheet itself be the list of symbols, which
is organised a lot better than a sort by symbol type then name
will ever be. I like the "these are for iteration" kind of
categorisation. I'd probably then remove the table right at
the top, so you have the module description and example above
the fold.

That's what I'm thinking at the moment anyway.

This is completely the wrong way to design anything. The design
needs rework if it can't handle the content. You don't shorten
the content to fit your design!

design look ridiculous on a large monitor.

Desktop: http://imgur.com/Xr25TJ8

and because the design is fixed and not responsive in *any* way
it also looks dire on mobile devices.

iPhone: http://imgur.com/fHduaH7

This is a poor amateurish design and i wish you would stop
right now. If this ever goes live not only will all developers
be extremely frustrated trying to actually read the
documentation but we as a community are going to be laughing
stock of the programming world!

This needs the attention of a professional designer and web
developer.

If you would like to contribute to the project, I am more than
happy to accept pull requests. I wouldn't try to judge too
harshly based on what you can see at the moment, as this project
is very much a work in progress. The majority of the work I've
been doing at the moment has just been technical to fit
everything into place.

If you are going to post screenshots of a design to criticise it,
I ask that you at least take the time to post accurate
screenshots. Whatever methods of resizing your browser window you
used completely failed to trigger the media queries which take
columns away as the screen size is reduced, as can be seen here.

https://imgur.com/dlSzuKo,6REhZng

The documentation doesn't fit so well into the screen size of the
original iPhone, which is 320 pixels wide, but easily fits into
screen sizes of the iPhone4 and above, which is 640 pixels and
above. I have been taking the time to edit code samples and test
against smaller screen sizes so the content fits comfortably.

You absolutely must change your content to fit it into smaller
screens. You cannot send a massive cargo plane to an airfield
which doesn't have large enough runways. You send smaller planes
to carry your freight to that airport. If you have a table where
the length of a symbol expands a single column too wide to fit
the second column's content on a phone screen comfortably, you
have to at the very least not use a table on the phone screens.

Regarding display at very large widths. that is something which
can be adjusted later. It's far easier to focus on fitting
content into smaller screen sizes first and then build outwards,
than it is to design everything for large screen sizes first and
then compact inwards. You can always expand column widths and
provide more non-essential but supllemental content afterwards so
the space is used effectively.

That said, there should be an upper limit, where beyond a given
width expanding to fill it entirely would not be a good idea. You
are always contrained by an upper limit on how long a line of
text should be. This doesn't have to be as small as 80 or 90
characters, as there are some studies which show that somewhere
as high as 100 or 110 characters per line can be read effectively.

Again, if you would like to contribute something of value, please
do not hesitate to do so.

Jul 27 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sun, Jul 27, 2014 at 08:43:48PM +0000, w0rp via Digitalmars-d wrote:
[...]
You absolutely must change your content to fit it into smaller
screens. You cannot send a massive cargo plane to an airfield which
doesn't have large enough runways. You send smaller planes to carry
your freight to that airport. If you have a table where the length of
a symbol expands a single column too wide to fit the second column's
content on a phone screen comfortably, you have to at the very least
not use a table on the phone screens.

I'm not a professional web developer, but isn't the current convention
to deliver two different CSS files for desktop vs. mobile browsers? I'm
not sure if it's a good idea to shoehorn a single design to fit two
vastly different display sizes and usage constraints.

T

--
Just because you survived after you did it, doesn't mean it wasn't stupid!

Jul 27 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 27 July 2014 at 23:38:44 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Sun, Jul 27, 2014 at 08:43:48PM +0000, w0rp via
Digitalmars-d wrote:
[...]
You absolutely must change your content to fit it into smaller
screens. You cannot send a massive cargo plane to an airfield
which
doesn't have large enough runways. You send smaller planes to
carry
your freight to that airport. If you have a table where the
length of
a symbol expands a single column too wide to fit the second
column's
content on a phone screen comfortably, you have to at the very
least
not use a table on the phone screens.

I'm not a professional web developer, but isn't the current
convention
to deliver two different CSS files for desktop vs. mobile
browsers? I'm
not sure if it's a good idea to shoehorn a single design to fit
two
vastly different display sizes and usage constraints.

T

To display more appropriate content for two different screen
sizes, you use CSS media queries to change the layout, which
typically just test the screen width. You can break this down
into separate files if you place the media queries on the 'link'
tag elements, or inside the CSS files if you use the media query
syntax in there. One option in a few cases is to show one element
at larger screen sizes, and another element at smaller screen
sizes. So you could use a table when there is more available
screen width, or sections and paragraphs when there is less
available screenw width. More commonly you will attempt use the
same elements for both, and reposition the subelements in a
similar manner.

Jul 27 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 28 July 2014 at 06:54:00 UTC, w0rp wrote:
media query syntax in there. One option in a few cases is to
show one element at larger screen sizes, and another element at
smaller screen sizes.

I think you should represent the information once. Otherwise
people using assistive technologies might run into problems.

So you could use a table when there is more available screen
width, or sections and paragraphs when there is less available
screenw width.

It is unlikely that people will spend a lot of time reading
tables on devices smaller than a tablet.

HTML allows the browser to break up tables. Tables are not meant
to be used for layout.

Even if browsers don't provide table optimized views, I'd suggest
sticking to semantic HTML rather than trying to implement fixes
for browsers not doing a good job. That might change in the
future.

Sure you can create a layout that will work fluidly with all
screen sizes without using javascript, but it takes extra work
when you create content. That extra work is probably better spent
creating a better experience for desktop use which is the primary
use scenario.

More commonly you will attempt use the same elements for both,
and reposition the subelements in a similar manner.

Yeah, but in reality you will often have to resort to javascript
or spend >100% more time on the layout structure, to make it work
on all screen sizes with just CSS (for a design that is a bit
more complicated than a book).

CSS is less powerful than XSL/XSLT, so if you want multiple
layouts maybe consider XSLT on the server instead.

Having the documentation in XML and mapping it to HTML using XSLT
has many advantages (such as generating PDF).

Jul 28 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 28 July 2014 at 07:51:51 UTC, Ola Fosheim GrÃ¸stad
wrote:
I think you should represent the information once. Otherwise
people using assistive technologies might run into problems.

(You might also run into SEO problems, getting a reduced ranking
in search engines, if you make lots of text invisible.)

Jul 28 2014
On Sunday, 27 July 2014 at 20:43:49 UTC, w0rp wrote:
You absolutely must change your content to fit it into smaller
screens. You cannot send a massive cargo plane to an airfield
which doesn't have large enough runways. You send smaller
planes to carry your freight to that airport. If you have a
table where the length of a symbol expands a single column too
wide to fit the second column's content on a phone screen
comfortably, you have to at the very least not use a table on
the phone screens.

This is total nonsense.

Regarding display at very large widths. that is something which
can be adjusted later. It's far easier to focus on fitting
content into smaller screen sizes first and then build
outwards, than it is to design everything for large screen
sizes first and then compact inwards. You can always expand
column widths and provide more non-essential but supllemental
content afterwards so the space is used effectively.

No, the current design is too small, period. Everything about it
is too small. The fonts, the column widths, the logo, etc.
Screens are getting bigger and screen resolutions are increasing.
Even tablets have 1080p+ resolutions.

That said, there should be an upper limit, where beyond a given
width expanding to fill it entirely would not be a good idea.
You are always contrained by an upper limit on how long a line
of text should be. This doesn't have to be as small as 80 or 90
characters, as there are some studies which show that somewhere
as high as 100 or 110 characters per line can be read
effectively.

Agreed but you are way below that sweet spot.

Again, if you would like to contribute something of value,
please do not hesitate to do so.

I am contributing but you are completely ignoring me and
attacking what i'm saying. I've been a professional web
application developer for years and have a lot of experience with
design and UX. Everybody here is completely ignoring that fact!
You don't even understand branding. So what's the point of me
trying to contribute?

Jul 28 2014
"w0rp" <devw0rp gmail.com> writes:
On Monday, 28 July 2014 at 07:29:48 UTC, Gary Willoughby wrote:
On Sunday, 27 July 2014 at 20:43:49 UTC, w0rp wrote:
You absolutely must change your content to fit it into smaller
screens. You cannot send a massive cargo plane to an airfield
which doesn't have large enough runways. You send smaller
planes to carry your freight to that airport. If you have a
table where the length of a symbol expands a single column too
wide to fit the second column's content on a phone screen
comfortably, you have to at the very least not use a table on
the phone screens.

This is total nonsense.

You wouldn't fit a very large page of sample code on a slide if
you wanted to show an example at a presentation, unless your
point was to show how bad it is to write too much code. You have
to write your sample such that it fits on the slide, so you will
remove braces you might otherwise use religiously, etc. It's not
total nonsense, it's common sense.

Regarding display at very large widths. that is something
which can be adjusted later. It's far easier to focus on
fitting content into smaller screen sizes first and then build
outwards, than it is to design everything for large screen
sizes first and then compact inwards. You can always expand
column widths and provide more non-essential but supllemental
content afterwards so the space is used effectively.

No, the current design is too small, period. Everything about
it is too small. The fonts, the column widths, the logo, etc.
Screens are getting bigger and screen resolutions are
increasing. Even tablets have 1080p+ resolutions.

I just explained that I was working with smaller screens and
working upwards, because it's a far more effective way to design
for all devices. This is why elements on the page currently fit
smaller screens better. I haven't taken the time to make
effective use of space for larger screen sizes yet. I'm well
aware of the 1080p resolution, because the layout fits well on a
1080p screen. The upper limit on screen widths I have worked for
so far is 1200 pixels, and slightly above that, which follows the
Bootstrap screen sizes.

That said, there should be an upper limit, where beyond a
given width expanding to fill it entirely would not be a good
idea. You are always contrained by an upper limit on how long
a line of text should be. This doesn't have to be as small as
80 or 90 characters, as there are some studies which show that
somewhere as high as 100 or 110 characters per line can be

Agreed but you are way below that sweet spot.

That is not true. The largest screen width accommodates about 95
CPL for paragraphs.

Again, if you would like to contribute something of value,
please do not hesitate to do so.

I am contributing but you are completely ignoring me and
attacking what i'm saying. I've been a professional web
application developer for years and have a lot of experience
with design and UX. Everybody here is completely ignoring that
fact! You don't even understand branding. So what's the point
of me trying to contribute?

nothing short of a personal attack on myself. If you wish to make
a serious contribution to a project, you should learn to use more
tact, and speak to objective points of argument. A meaningful
contribution would consist of contributing art assets, writing
CSS, drafting mock-ups for improvements, etc. Thus far, you have
failed to do any of this.

Jul 28 2014
On Monday, 28 July 2014 at 08:30:05 UTC, w0rp wrote:
nothing short of a personal attack on myself. If you wish to
make
a serious contribution to a project, you should learn to use
more
tact, and speak to objective points of argument. A meaningful
contribution would consist of contributing art assets, writing
CSS, drafting mock-ups for improvements, etc. Thus far, you have
failed to do any of this.

I'm speaking the truth which often hurts.

Your problem is you are not able to take any criticism whatsoever
against this piece of work. The design is awful, period.

I have nothing against you personally and i think it's good that
you are initiating this effort but the design is the first thing
that should be addressed and in no way be an afterthought. I
apologise if i sound terse but usually in my line of work shoddy
efforts have to be address upfront and with prejudice.

The very first thing you should of done is to create mockups (in
photoshop, etc) of what each page should look like and make sure
the design can accommodate all the content. Once the design is
approved then implement the site. The backend is inconsequential,
use whatever you are comfortable with. Vibe.d, LAMP it doesn't
matter. Users don't care about the backend. What matters is the
user experience (especially within the documentation) and that is
what should be addressed in a thoughtful professional matter.
This is not optional or something that should be done along the
way.

Jul 28 2014
"uri" <email ether.com> writes:
On Monday, 28 July 2014 at 09:16:44 UTC, Gary Willoughby wrote:

You said you don't like it and you were heard the first time

I'm speaking the truth which often hurts.

Yes and I don't see w0rp running off and sulking about it either.

Your problem is you are not able to take any criticism
whatsoever against this piece of work. The design is awful,
period.

I have nothing against you personally and i think it's good
that you are initiating this effort but the design is the first
thing that should be addressed and in no way be an
afterthought. I apologise if i sound terse but usually in my
line of work shoddy efforts have to be address upfront and with
prejudice.

because you say you know how to do a better job.

The very first thing you should of done is to create mockups
(in photoshop, etc) of what each page should look like and make
sure the design can accommodate all the content. Once the
design is approved then implement the site. The backend is
inconsequential, use whatever you are comfortable with. Vibe.d,
LAMP it doesn't matter. Users don't care about the backend.
What matters is the user experience (especially within the
documentation) and that is what should be addressed in a
thoughtful professional matter. This is not optional or
something that should be done along the way.

Stating something is crap in a volunteer project is useless
unless you can follow it up with something equally useful.

For an engineer you sound just like our marketing team at work:
Always ready to produce some warm and fuzzy ideas but light on
the specifics and actual work.

/uri

Jul 28 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 28 July 2014 at 09:16:44 UTC, Gary Willoughby wrote:
Your problem is you are not able to take any criticism
whatsoever against this piece of work. The design is awful,
period.

Criticism is worthless if you are not ready to actually do
something about it - providing detailed list of necessary changes
at the very least. D development has always been about going and
getting stuff done - same principle apply here. If you have
professional web development experience that may help here -
start helping somehow. Otherwise this criticism is just
distraction.

Jul 28 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:
going and getting stuff done - same principle apply here. If
you have professional web development experience that may help
here - start helping somehow.

You need to define and agree on a process first. If not you will
have to redo the site 10 times before getting to the end result.
Then you will have to redo it whenever someone decides to add a
feature that contradicts the design/layout, because they assumed
that it would be easy to add later.

What are the key requirements?

What is the primary user base (front page, doc pages etc)

What are the main target platforms?

What is the intermediate format?

What is the primary use scenarios?

What are the key future functionality that it has to accomodate?

What nice-to-haves can we cut in order to reduce work?

Who gets the final word when you cannot get a decision?

etc.

Jul 28 2014
On Monday, 28 July 2014 at 11:35:21 UTC, Ola Fosheim GrÃ¸stad
wrote:
On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:
going and getting stuff done - same principle apply here. If
you have professional web development experience that may help
here - start helping somehow.

You need to define and agree on a process first. If not you
will have to redo the site 10 times before getting to the end
result. Then you will have to redo it whenever someone decides
they assumed that it would be easy to add later.

What are the key requirements?

What is the primary user base (front page, doc pages etc)

What are the main target platforms?

What is the intermediate format?

What is the primary use scenarios?

What are the key future functionality that it has to accomodate?

What nice-to-haves can we cut in order to reduce work?

Who gets the final word when you cannot get a decision?

etc.

At last somebody else who understands.

Jul 28 2014
"Dicebot" <public dicebot.lv> writes:
On Monday, 28 July 2014 at 11:35:21 UTC, Ola Fosheim GrÃ¸stad
wrote:
On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:
going and getting stuff done - same principle apply here. If
you have professional web development experience that may help
here - start helping somehow.

You need to define and agree on a process first. If not you
will have to redo the site 10 times before getting to the end
result. Then you will have to redo it whenever someone decides
they assumed that it would be easy to add later.

What are the key requirements?

What is the primary user base (front page, doc pages etc)

What are the main target platforms?

What is the intermediate format?

What is the primary use scenarios?

What are the key future functionality that it has to accomodate?

What nice-to-haves can we cut in order to reduce work?

Who gets the final word when you cannot get a decision?

etc.

It has never worked that way with D development process and I
don't see it happening without any major structural changes.
Pretty much everything that does not come from Walter or Andrei
is decentralized anarchy-driven development - you do something,
show it to community, see results.

All these questions are nonsense crap without someone actually
willing to do the work. Such attitude may insult professionals
but there are no hired professionals working here.

Jul 28 2014
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/28/14, 12:29 AM, Gary Willoughby wrote:
I am contributing but you are completely ignoring me and attacking what
i'm saying. I've been a professional web application developer for years
and have a lot of experience with design and UX. Everybody here is
completely ignoring that fact! You don't even understand branding. So
what's the point of me trying to contribute?

I've been in similar situations in the past so I sympathize. The one
thing I noticed gets the point across is to just do good work and just
show it. People otherwise ignorant of what goes into a piece of work
_can_ often appreciate a compelling end result.

Andrei

Jul 28 2014
On Monday, 28 July 2014 at 16:58:53 UTC, Andrei Alexandrescu
wrote:
On 7/28/14, 12:29 AM, Gary Willoughby wrote:
I am contributing but you are completely ignoring me and
attacking what
i'm saying. I've been a professional web application developer
for years
and have a lot of experience with design and UX. Everybody
here is
completely ignoring that fact! You don't even understand
branding. So
what's the point of me trying to contribute?

I've been in similar situations in the past so I sympathize.
The one thing I noticed gets the point across is to just do
good work and just show it. People otherwise ignorant of what
goes into a piece of work _can_ often appreciate a compelling
end result.

Andrei

It is frustrating because i want this to be done well as it could
really help D take off. If it's done poorly we will be the
laughing stock especially as our immediate competition is other
programming sites.

https://www.python.org/
https://developer.apple.com/swift/
https://www.ruby-lang.org
http://www.perl.org/
https://www.dartlang.org/

If the new D site isn't at least as good as any of the above we
have failed. I'm up to my eye balls in other projects at the
minute so i can't contribute any code.

Jul 28 2014
"Kagamin" <spam here.lot> writes:
On Monday, 28 July 2014 at 17:23:37 UTC, Gary Willoughby wrote:
It is frustrating because i want this to be done well as it
could really help D take off.

Doing it on LAMP won't help D to take off. In a sense, you don't
even criticize this work, as a professional web designer, you can
provide a constructive feedback, if you assess, whether the D web
stack is ready for use by a web designer, whether SSI is done
right, what features are missing or confusing, is it easy do
setup a development environment. If LAMP is better, you can
report the problems.

https://www.dartlang.org/

Actually bad scrolling UX because of the floating panel.

Jul 29 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jul 28, 2014 at 09:58:59AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 7/28/14, 12:29 AM, Gary Willoughby wrote:
I am contributing but you are completely ignoring me and attacking
what i'm saying. I've been a professional web application developer
for years and have a lot of experience with design and UX. Everybody
here is completely ignoring that fact! You don't even understand
branding. So what's the point of me trying to contribute?

Your hostile tone may have contributed to that reaction, however
justified your arguments may have been. Coming into a volunteer project
and telling people things like "this is garbage", "this is amateurish",
"you should stop", "you don't understand anything at all", is very
hostile, and therefore likely to provoke a negative reaction, even if
the work concerned actually *is* garbage, amateurish, etc..

As Andrei said (quoted below), if instead of tearing others'
(voluntary!) work into pieces, you produce a superior piece of work and
show it (even if it's just a concept sketch of the end result, not the
actual implementation), it will be much more convincing, and people will
be much more likely to listen to you. As they say, "show, don't tell".

I've been in similar situations in the past so I sympathize. The one
thing I noticed gets the point across is to just do good work and just
show it.  People otherwise ignorant of what goes into a piece of work
_can_ often appreciate a compelling end result.

[...]

T

--
Many open minds should be closed for repairs. -- K5 user

Jul 28 2014
On Sunday, 27 July 2014 at 06:10:09 UTC, Andrei Alexandrescu
wrote:
On 7/26/14, 8:47 PM, H. S. Teoh via Digitalmars-d wrote:
On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 7/26/14, 6:30 PM, w0rp wrote:
The std.algortihm documentation doesn't look good, and I
don't have
any good ideas for it.

I find std.algorithm among the best documented libraries out
there! I
must be in denial... -- Andrei

"No, I'm not in denial! It can't be!!!"

Well correction: I think it's among the better documented
modules in std. -- Andrei

Still, all the documentation do not looks good.

Aug 21 2014
Timon Gehr <timon.gehr gmx.ch> writes:
On 07/27/2014 04:39 AM, Andrei Alexandrescu wrote:
On 7/26/14, 6:30 PM, w0rp wrote:
The std.algortihm documentation doesn't look good, and I don't have any
good ideas for it.

I find std.algorithm among the best documented libraries out there! I

^~~~~~~~~~~~~~~~~~~

This actually tripped me up while speed-reading. :o) Intended?

must be in denial... -- Andrei


Jul 28 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.07.2014 00:54, schrieb w0rp:
http://w0rp.com:8010/library/index.html

Since the site is running with vibe.d anyway, I'd think about using
registerApiDocs() instead of generating individual HTML files. This
gives much nicer URLs and also avoids potential issues with file systems
that are case insensitive. See http://vibed.org/api/ for an example.

Jul 27 2014
"w0rp" <devw0rp gmail.com> writes:
On Sunday, 27 July 2014 at 16:32:15 UTC, SÃ¶nke Ludwig wrote:
Am 27.07.2014 00:54, schrieb w0rp:
http://w0rp.com:8010/library/index.html

Since the site is running with vibe.d anyway, I'd think about
using registerApiDocs() instead of generating individual HTML
files. This gives much nicer URLs and also avoids potential
issues with file systems that are case insensitive. See
http://vibed.org/api/ for an example.

I have just been playing with this during this evening by
learning from the source for the vibed.org website. I managed to
integrate serving the documentation pages from /library/ just
fine. This is a definite improvement. Thank you for the
suggestion. At the very, very least, the URLs are cleaner this
way. If this is paired with some automatic recompliation of Diet
templates too, then it could be much more convenient to work with.

I set up the ddoc macros by calling the setDefaultDdocMacroFiles
and setOverrideDdocMacroFiles functions, which sets them in the
global scope. This could be better, but I couldn't figure out if
there was a way to provide the .ddoc macros to use per Package
object or similar. This doesn't matter too much right now, but it
might be nice in future to provide documentation for historical D
language versions too in future, like on the vibe.d site.

You can see some running examples on the site now.

http://w0rp.com:8010/library/std.parallelism/

Obviously if it stays that way, some 301 redirects will have to
be set up pointing from the old URLs to the new ones. I've been
setting up a few as I go already.

I'll look at playing with the style of the documentation pages
some more another evening. I've had a few ideas for improvements,
and I obviously still need to include syntax highlighting. Is
this the library which is being used on the live site now for
that?

I'd be happy to go with that for now, or whatever else if anyone
has any better suggestions. I used hightlight.js on my personal
site to some success, but I remember thinking that the
highlighting could have been better with it a few times.

http://highlightjs.org/

That's all for now.

Jul 28 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 29.07.2014 00:04, schrieb w0rp:
On Sunday, 27 July 2014 at 16:32:15 UTC, SÃ¶nke Ludwig wrote:
Am 27.07.2014 00:54, schrieb w0rp:
http://w0rp.com:8010/library/index.html

Since the site is running with vibe.d anyway, I'd think about using
registerApiDocs() instead of generating individual HTML files. This
gives much nicer URLs and also avoids potential issues with file
systems that are case insensitive. See http://vibed.org/api/ for an
example.

I have just been playing with this during this evening by learning from
the source for the vibed.org website. I managed to integrate serving the
documentation pages from /library/ just fine. This is a definite
improvement. Thank you for the suggestion. At the very, very least, the
URLs are cleaner this way. If this is paired with some automatic
recompliation of Diet templates too, then it could be much more
convenient to work with.

I set up the ddoc macros by calling the setDefaultDdocMacroFiles and
setOverrideDdocMacroFiles functions, which sets them in the global
scope. This could be better, but I couldn't figure out if there was a
way to provide the .ddoc macros to use per Package object or similar.
This doesn't matter too much right now, but it might be nice in future
to provide documentation for historical D language versions too in
future, like on the vibe.d site.

The DocGroupContext class currently returns null for its
overrideMacroDefinitions and defaultMacroDefinitions properties. This
would just have to be extended so that it becomes possible to inject
custom values. I've added a ticket for that:
https://github.com/rejectedsoftware/ddox/issues/51

You can see some running examples on the site now.

http://w0rp.com:8010/library/std.parallelism/

Obviously if it stays that way, some 301 redirects will have to be set
up pointing from the old URLs to the new ones. I've been setting up a

There is also a pending change for the current documentation that
changes the current link style (balancedParens.html) to lowercase
underscore notation (balanced_parens.html), so there will be a bunch of
redirects already. One issue with this is that the new style will
sometimes have ambiguous redirects to the canonical style
(balancedParens) because it removes the case information, but I don't
really see a way around that.

I'll look at playing with the style of the documentation pages some more
another evening. I've had a few ideas for improvements, and I obviously
still need to include syntax highlighting. Is this the library which is
being used on the live site now for that?

That plus some modifications to add D support. But my plan was to use
server side highlighting using Brian Schott's lexer in the future.

Jul 28 2014
"w0rp" <devw0rp gmail.com> writes:
On Monday, 28 July 2014 at 22:38:10 UTC, SÃ¶nke Ludwig wrote:
I'll look at playing with the style of the documentation pages
some more
another evening. I've had a few ideas for improvements, and I
obviously
still need to include syntax highlighting. Is this the library
which is
being used on the live site now for that?

That plus some modifications to add D support. But my plan was
to use server side highlighting using Brian Schott's lexer in
the future.

That's probably a good call. Were you thinking of discovering
<code> blocks in pages and running the lexer on them to produce
the formatted output?

Jul 28 2014
=?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 29.07.2014 00:54, schrieb w0rp:
On Monday, 28 July 2014 at 22:38:10 UTC, SÃ¶nke Ludwig wrote:
I'll look at playing with the style of the documentation pages some more
another evening. I've had a few ideas for improvements, and I obviously
still need to include syntax highlighting. Is this the library which is
being used on the live site now for that?

That plus some modifications to add D support. But my plan was to use
server side highlighting using Brian Schott's lexer in the future.

That's probably a good call. Were you thinking of discovering <code>
blocks in pages and running the lexer on them to produce the formatted
output?

The other way around. DDOX and the Markdown processor would directly
call the syntax highlighter on code sections they encounter. The result
would then directly be written to the output range.

Jul 29 2014
"w0rp" <devw0rp gmail.com> writes:
On Tuesday, 29 July 2014 at 08:27:40 UTC, SÃ¶nke Ludwig wrote:
Am 29.07.2014 00:54, schrieb w0rp:
On Monday, 28 July 2014 at 22:38:10 UTC, SÃ¶nke Ludwig wrote:
I'll look at playing with the style of the documentation
pages some more
another evening. I've had a few ideas for improvements, and
I obviously
still need to include syntax highlighting. Is this the
library which is
being used on the live site now for that?

That plus some modifications to add D support. But my plan
was to use
server side highlighting using Brian Schott's lexer in the
future.

That's probably a good call. Were you thinking of discovering
<code>
blocks in pages and running the lexer on them to produce the
formatted
output?

The other way around. DDOX and the Markdown processor would
directly call the syntax highlighter on code sections they
encounter. The result would then directly be written to the
output range.

Sounds good to me. This is starting to remind me of Inception. A
D website running on vibe.d which invokes a D compiler to produce
D documentation which produces syntax highlighting for D code
blocks using a D lexer.

Jul 29 2014
"Colin" <grogan.colin gmail.com> writes:
On Tuesday, 29 July 2014 at 08:51:43 UTC, w0rp wrote:
On Tuesday, 29 July 2014 at 08:27:40 UTC, SÃ¶nke Ludwig wrote:
Am 29.07.2014 00:54, schrieb w0rp:
On Monday, 28 July 2014 at 22:38:10 UTC, SÃ¶nke Ludwig wrote:
I'll look at playing with the style of the documentation
pages some more
another evening. I've had a few ideas for improvements, and
I obviously
still need to include syntax highlighting. Is this the
library which is
being used on the live site now for that?

That plus some modifications to add D support. But my plan
was to use
server side highlighting using Brian Schott's lexer in the
future.

That's probably a good call. Were you thinking of discovering
<code>
blocks in pages and running the lexer on them to produce the
formatted
output?

The other way around. DDOX and the Markdown processor would
directly call the syntax highlighter on code sections they
encounter. The result would then directly be written to the
output range.

Sounds good to me. This is starting to remind me of Inception. A
D website running on vibe.d which invokes a D compiler to
produce
D documentation which produces syntax highlighting for D code
blocks using a D lexer.

Confusing sentence. Deception at it's finest.

/sorry

Jul 29 2014
"Anonymous" <a a.com> writes:
Random guy here. I think the redesign is good. Populating the On
This Page box with the function, enum etc. names would be nice.
mode is essential, be it switching to boxes at the top/bottom of
the page or minimizing/maximizing the side bars. But maybe you're
Maybe the full width view could have a wider documentation body
or dynamically scale up text, but it works fine as it is. As a
tree style tabs plus side taskbar user I don't see all that much
half-width is a killer feature over D's current web docs,
especially on desktops without workspaces.

Jul 30 2014
"Hubert" <rutgermegahertz gmail.com> writes:
First I wanna say that I've become a huge fan of D, and I hope
one day I can replace all my creative projects with a D codebase.
With that said, I do agree that D could use a redesign. I've not
been monitoring this thread very closely, but the design
suggestions I've seen so far has dissapointed me. Don't
misunderstand me; the proposals look good, but they are in my
opinion too conservative.

Now I've given it a shot and created a first draft on how I
imagine a future Dlang.org could/should look like, keep in mind
that nothing is final yet:

https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

My emphasis has been on creating a friendly first impression; a
lightweight page to introduce newcomers to D and get them started
quickly. I think this is a sane design approach when it comes to
D's current position in the "market". I've not yet begun any work
on the views for the documentation and similar pages with a
larger amount of copy.

(I hope I haven't missed any earlier design proposal that already
looks like this.)

Aug 20 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

My emphasis has been on creating a friendly first impression; a
lightweight page to introduce newcomers to D and get them
started quickly.

+1 Cool look! The paragraphs need to be black on light background
to get high contrast for all user groups, though. (You will also
meet resistance on changing the logo...)

I've not yet begun any work on the views for the documentation
and similar pages with a larger amount of copy.

The documentation could have black on white (white paper meme),
but same visual elements to get a sense of subsite areas.

Aug 21 2014
Jacob Carlborg <doob me.com> writes:
On 21/08/14 06:59, Hubert wrote:

https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

I kind of like the structure of the page, but not the colors.

--
/Jacob Carlborg

Aug 21 2014
"Dicebot" <public dicebot.lv> writes:
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
First I wanna say that I've become a huge fan of D, and I hope
one day I can replace all my creative projects with a D
codebase. With that said, I do agree that D could use a
redesign. I've not been monitoring this thread very closely,
but the design suggestions I've seen so far has dissapointed
me. Don't misunderstand me; the proposals look good, but they
are in my opinion too conservative.

Now I've given it a shot and created a first draft on how I
imagine a future Dlang.org could/should look like, keep in mind
that nothing is final yet:

https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

My emphasis has been on creating a friendly first impression; a
lightweight page to introduce newcomers to D and get them
started quickly. I think this is a sane design approach when it
comes to D's current position in the "market". I've not yet
begun any work on the views for the documentation and similar
pages with a larger amount of copy.

(I hope I haven't missed any earlier design proposal that

It probably looks good as a landing page for a newcomers but I
will annoyed with extra forced navigation very quick through
daily usage of the web site. It sacrifices productivity in favor
of good looks.

Aug 21 2014
ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 21 Aug 2014 12:09:37 +0000
Dicebot via Digitalmars-d <digitalmars-d puremagic.com> wrote:

It probably looks good as a landing page for a newcomers but I=20
will annoyed with extra forced navigation very quick through=20
daily usage of the web site. It sacrifices productivity in favor=20
of good looks.

exactly what i wanted to say, but cannot find the appropriate words!

Aug 21 2014
"Kagamin" <spam here.lot> writes:
On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:
It probably looks good as a landing page for a newcomers but I
will annoyed with extra forced navigation very quick through
daily usage of the web site. It sacrifices productivity in
favor of good looks.

Hmm... I don't remember, when I last visited the front page, I
don't even know, what it looks like. What one would need there
and what productivity you plan to get there?

Aug 21 2014
"Dicebot" <public dicebot.lv> writes:
On Thursday, 21 August 2014 at 15:14:05 UTC, Kagamin wrote:
On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:
It probably looks good as a landing page for a newcomers but I
will annoyed with extra forced navigation very quick through
daily usage of the web site. It sacrifices productivity in
favor of good looks.

Hmm... I don't remember, when I last visited the front page, I
don't even know, what it looks like. What one would need there
and what productivity you plan to get there?

I check various parts of documentation (not DDOC-generates Phobos
part but manually written articles) on a regular basis. It is
often faster to find via navigating then search query because
term usage is spread all across.

Aug 21 2014
"Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 21 August 2014 at 15:16:52 UTC, Dicebot wrote:
I check various parts of documentation (not DDOC-generates
Phobos part but manually written articles) on a regular basis.
It is often faster to find via navigating then search query
because term usage is spread all across.

But you will get all that from the documentation subsection?

I do think the frontpage should indicate that D is a systems
programming language, though. I also think code samples that
highlight main language features constructs belong on the front
page. It should try to quickly give an enticing answer to
questions like these:

What is this D thing google sent me to?
What does it look like?
Is this project abandoned or active?
Where can I get a trouble free install?
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?
Bugfix responsiveness?
Etc..

Aug 21 2014
"Kagamin" <spam here.lot> writes:
On Thursday, 21 August 2014 at 15:16:52 UTC, Dicebot wrote:
On Thursday, 21 August 2014 at 15:14:05 UTC, Kagamin wrote:
On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:
It probably looks good as a landing page for a newcomers but
I will annoyed with extra forced navigation very quick
through daily usage of the web site. It sacrifices
productivity in favor of good looks.

Hmm... I don't remember, when I last visited the front page, I
don't even know, what it looks like. What one would need there
and what productivity you plan to get there?

I check various parts of documentation (not DDOC-generates
Phobos part but manually written articles) on a regular basis.
It is often faster to find via navigating then search query
because term usage is spread all across.

Such things should be probably integrated in a documentation
start page: language reference, library reference, articles,
papers, wiki, howtos, books. There's too much to integrate into

Aug 24 2014
"Hubert" <rutgermegahertz gmail.com> writes:
Thanks for the response! I do agree that the colors are way too
"hot" (I've must've been quite tired when I submitted that mockup)

Someone noted that the concept that I pitched had too much
whitespace, which is a sentiment that I do not share. There's a
lot of issues with the readability in the current design; way too
wide columns just to name one thing. I must also completely
disagree with the "90's anachronism" part.

You may feel that a "Getting started" section and simplified
is the site supposed to cater to the entrenched D-practitioners?
As long as the readability and the layout of the documentation is
accurate and clear what does it matter to you? There's not any
inherent value in complexity.

Aug 28 2014
"Dicebot" <public dicebot.lv> writes:
On Friday, 29 August 2014 at 02:36:22 UTC, Hubert wrote:
You may feel that a "Getting started" section and simplified
but is the site supposed to cater to the entrenched
D-practitioners? As long as the readability and the layout of
the documentation is accurate and clear what does it matter to
you? There's not any inherent value in complexity.

I simply don't see good layout fitting into the same style. And
having documentation sub-pages with totally different design is
also pretty bad from the point of view of the visual style.

If you can show any sketches how it can be used for more
technical content I may be convinced :)

Aug 28 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Aug 29, 2014 at 02:36:21AM +0000, Hubert via Digitalmars-d wrote:
Thanks for the response! I do agree that the colors are way too "hot"
(I've must've been quite tired when I submitted that mockup)

Someone noted that the concept that I pitched had too much whitespace,
which is a sentiment that I do not share. There's a lot of issues with
the readability in the current design; way too wide columns just to
name one thing. I must also completely disagree with the "90's
anachronism" part.

You may feel that a "Getting started" section and simplified
the site supposed to cater to the entrenched D-practitioners? As long
as the readability and the layout of the documentation is accurate and
clear what does it matter to you? There's not any inherent value in
complexity.

insulting or inefficient. But I do say the simplification should be via
watch completely irrelevant marketing video" makes no sense, whereas a
breakdown like "News / Download / Get started with D / Reference
documentation / Compiler specs / etc." makes sense.

Content-less splash pages are, to me, completely worthless. A
properly-designed front page with sensible top-level links to sensible
categories, properly designed, will both look and work better. A proper
design need not sacrifice content for appeal.

T

--
Never trust an operating system you don't have source for! -- Martin Schulze

Aug 28 2014
=?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
 On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

This is a brilliant idea, except for the logo. We have one, and
with it an identity, and we should not loose it.

On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:
It probably looks good as a landing page for a newcomers but I
will annoyed with extra forced navigation very quick through
daily usage of the web site. It sacrifices productivity in
favor of good looks.

There is too much links in our actual homepage, newcomers are
simply lost, we absolutely need to light it, to make it more
friendly.

The question is : is it more important to maintain your old
habits or to be welcoming and attractive for the new users ?

Don't forget that programmers are hipsters, and we need to take
care of our image.

Aug 21 2014
"Dicebot" <public dicebot.lv> writes:
On Thursday, 21 August 2014 at 17:12:38 UTC, ThÃ©o Bueno wrote:
On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote:
It probably looks good as a landing page for a newcomers but I
will annoyed with extra forced navigation very quick through
daily usage of the web site. It sacrifices productivity in
favor of good looks.

There is too much links in our actual homepage, newcomers are
simply lost, we absolutely need to light it, to make it more
friendly.

The question is : is it more important to maintain your old
habits or to be welcoming and attractive for the new users ?

Don't forget that programmers are hipsters, and we need to take
care of our image.

I prefer to have my cake and eat it at the same time. There is no
reason why it can't have better navigation while making important
information highlighted and visually eye-catching.

Also please avoid personal insults :P

Aug 21 2014
=?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
On Thursday, 21 August 2014 at 17:15:30 UTC, Dicebot wrote:
I prefer to have my cake and eat it at the same time. There is
no reason why it can't have better navigation while making
important information highlighted and visually eye-catching.

Of course :)

Also please avoid personal insults :P

I wasn't insulting, my intention was to mention the fact that
this argument is not entirely a matter of productivity, but a
fear of change.

Aug 21 2014
"Dicebot" <public dicebot.lv> writes:
On Thursday, 21 August 2014 at 17:24:28 UTC, ThÃ©o Bueno wrote:
Also please avoid personal insults :P

I wasn't insulting, my intention was to mention the fact that
this argument is not entirely a matter of productivity, but a
fear of change.

I was referring to "Don't forget that programmers are hipsters"
statement ;)

Aug 21 2014
=?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
On Thursday, 21 August 2014 at 17:31:45 UTC, Dicebot wrote:
On Thursday, 21 August 2014 at 17:24:28 UTC, ThÃ©o Bueno wrote:
Also please avoid personal insults :P

I wasn't insulting, my intention was to mention the fact that
this argument is not entirely a matter of productivity, but a
fear of change.

I was referring to "Don't forget that programmers are hipsters"
statement ;)

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

Aug 21 2014
Matt Soucy <msoucy csh.rit.edu> writes:
On 08/21/2014 01:37 PM, "Th=C3=A9o Bueno" <munrek gmx.com>" wrote:
On Thursday, 21 August 2014 at 17:31:45 UTC, Dicebot wrote:
On Thursday, 21 August 2014 at 17:24:28 UTC, Th=C3=A9o Bueno wrote:
Also please avoid personal insults :P

I wasn't insulting, my intention was to mention the fact that
this argument is not entirely a matter of productivity, but a
fear of change.

I was referring to "Don't forget that programmers are hipsters" statem=

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

Duck hipstering - if it looks like a hipster, acts like a hipster...it wa=
s a hipster before it was cool. Stop declaring your hipsters as "auto" :P=

--=20
Matt Soucy
http://msoucy.me/

Aug 23 2014
=?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
On Thursday, 21 August 2014 at 17:12:38 UTC, ThÃ©o Bueno wrote:
There is too much links in our actual homepage, newcomers are
simply lost, we absolutely need to light it, to make it more
friendly.

Also, please see this message :

It explains why we need a big red "get started" button to help
the newcomers. This person was not able to find relevant
informations on IDEs, despite our big stack of links on the
homepage. This is also a lack of productivity.

Aug 21 2014
ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 21 Aug 2014 17:12:37 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:

Don't forget that programmers are hipsters, and we need to take
care of our image.

i'm glad that i'm not a programmer then.

Aug 21 2014
"Meta" <jared771 gmail.com> writes:
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

That does look quite nice. It may be a bit *too* minimalist, and
the colours aren't right, but the design is solid.

Aug 21 2014
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Aug 21, 2014 at 04:59:18AM +0000, Hubert via Digitalmars-d wrote:
[...]
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

My emphasis has been on creating a friendly first impression; a
lightweight page to introduce newcomers to D and get them started
quickly. I think this is a sane design approach when it comes to D's
current position in the "market". I've not yet begun any work on the
views for the documentation and similar pages with a larger amount of
copy.

(I hope I haven't missed any earlier design proposal that already
looks like this.)

[...]

Please don't take this personally, but frankly, I don't like this
design. It's too minimalistic, the choice of color is too garish, and
the logo looks amateurish. There is too much space in the center of the
page, while squeezing the real information to the sides. I very much
dislike the current splash page + "get started" / "learn more" trend, an
anachronism from the 90's. It requires too much effort to get to the
meat of the site, and serves little purpose except to fill up space.
More navigation can be put on the front page without requiring
inordinate amounts of clicks to reach (properly laid out, of course, to
avoid clutter).

Having said that, though, I like the concept of putting the
"convenience, power, efficiency" slogans in a prominent place, side by
side. That's something far superior to the current layout we have, where
most people won't even see everything until they scroll down.

T

--
Unix is my IDE. -- Justin Whear

Aug 21 2014
"w0rp" <devw0rp gmail.com> writes:
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
First I wanna say that I've become a huge fan of D, and I hope
one day I can replace all my creative projects with a D
codebase. With that said, I do agree that D could use a
redesign. I've not been monitoring this thread very closely,
but the design suggestions I've seen so far has dissapointed
me. Don't misunderstand me; the proposals look good, but they
are in my opinion too conservative.

Now I've given it a shot and created a first draft on how I
imagine a future Dlang.org could/should look like, keep in mind
that nothing is final yet:

https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

My emphasis has been on creating a friendly first impression; a
lightweight page to introduce newcomers to D and get them
started quickly. I think this is a sane design approach when it
comes to D's current position in the "market". I've not yet
begun any work on the views for the documentation and similar
pages with a larger amount of copy.

(I hope I haven't missed any earlier design proposal that

I'm not a fan of the colours and the general way it looks, but I
do really like the three columns of text for the three big
points. I'm not sure how to put that on a home page and keep some
consistent navigation in place, so that would require some
playing around with. You could maybe sacrifice sidebar navigation
on the home page to allow enough space to fit in the text columns
at 1024px width, I'm not sure.

A few other people have mentioned fluid container widths. I
actually know exactly what to do with that, I just haven't gotten
around to doing it yet. I think I make some progress, but then
life gets in the way a little bit. I'll come back to it soon and
work a little more on the site.

Aug 21 2014
"Weaseldog" <weaseldog gmail.com> writes:
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote:
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png

My emphasis has been on creating a friendly first impression; a
lightweight page to introduce newcomers to D and get them
started quickly. I think this is a sane design approach when it
comes to D's current position in the "market". I've not yet
begun any work on the views for the documentation and similar
pages with a larger amount of copy.

(I hope I haven't missed any earlier design proposal that

Sort of reminds me of Ocaml's webpage, but more minimalistic.

I think a lot of good ideas could come from looking at other
language's webpages, Haskell's new webpage is similar to Ocaml's
but has less content(it's also not finished yet)

Aug 21 2014
Matt Soucy <msoucy csh.rit.edu> writes:
On 08/21/2014 12:59 AM, Hubert wrote:
First I wanna say that I've become a huge fan of D, and I hope one day =

I can replace all my creative projects with a D codebase. With that said,=
I do agree that D could use a redesign. I've not been monitoring this th=
read very closely, but the design suggestions I've seen so far has dissap=
ointed me. Don't misunderstand me; the proposals look good, but they are =
in my opinion too conservative.
=20
Now I've given it a shot and created a first draft on how I imagine a f=

uture Dlang.org could/should look like, keep in mind that nothing is fina=
l yet:
=20
https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png
=20
My emphasis has been on creating a friendly first impression; a lightwe=

ight page to introduce newcomers to D and get them started quickly. I thi=
nk this is a sane design approach when it comes to D's current position i=
n the "market". I've not yet begun any work on the views for the document=
ation and similar pages with a larger amount of copy.
=20
(I hope I haven't missed any earlier design proposal that already looks=

like this.)
=20
=20

It reminds me a lot of http://zeromq.org/, which is TOLERABLE not not, in=
my opinion, great.

--=20
Matt Soucy
http://msoucy.me/

Aug 23 2014
"yawniek" <dlang srtnwz.com> writes:
On Monday, 28 July 2014 at 22:04:45 UTC, w0rp wrote:
On Sunday, 27 July 2014 at 16:32:15 UTC, SÃ¶nke Ludwig wrote:
Am 27.07.2014 00:54, schrieb w0rp:

You can see some running examples on the site now.

http://w0rp.com:8010/library/std.parallelism/

cool stuff, congrats on the progress, i really like it!

from a usability perspective i have two suggestions:

1) re-add the alphabetic list of classes, functions etc, either
on top or better in a sidebar as e.g. ruby has it:
http://ruby-doc.org/core-2.2.0/String.html
it helps a lot if you are new and want to get a quick overview
whats possible within a given module.

2) currently clicking on a function name opens a new site with
the doc of that function.
why not load it inline in a collapsable fragment? (could also be
a simple + button that allows this in addition to the link)
this would greatly help when quickly going trough a number of
functions in a module.

cheers
y

Jan 02
Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 4 Jul 2014 08:40, "Russel Winder via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote:
[=E2=80=A6]

SarcasticRover is telling us "Do not come to Mars." Perhaps its
commentary need censoring ;-)


Jul 04 2014
"Chris" <wendlec tcd.ie> writes:
On Thursday, 3 July 2014 at 17:38:22 UTC, w0rp wrote:
On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote:
the design, it's a good starting point. Especially the
integration of the logo. Nice and clean. (The current logo is
just too bulky and clumsy, imo*)

However, my experience tells me that we should wait with
redesigning it until the technical issues/problems have been
solved, e.g. the migration to vibe.d, which I'm in favor of
(I've had good experiences with vibe.d so far), and the doc
generation issue etc etc. Once that is out of the way, we can

I've been focusing on getting a working site with vibe.d.
Integrating the ddox document generator is a high priority for
me right now, especially since I've finished a lot of work for
formatting the changelog pages.

Yours is very nice and "modern". However, we also have to take
mobile devices (tablets, smartphones) into account and see how
we can adapt to these (different layouts or one for all?).

I used the Bootstrap framework, which I have also used in my
day job. Bootstrap makes producing a responsive design pretty
easy. I've been periodically testing pages on smaller screens.
Firefox's 'reponsive design mode' helps a lot with this.

Another issue is that we don't have to jump on any bandwagon
(every time the "fashion" changes), we can roll our own
design, one that fits the community's and the language's
needs, regardless of what is trendy or "modern" at any given
time (don't imitate, innovate!).

There are many different designs you could produce. Many design
choices are subjective, though not all of them. I think my
goals for the work I've been doing are as follows.

* Improve display across different devices.
* Improve the quality of text to make it easier to read.
* Make it easier for newcomers to edit, to encourage
contribution.
* Run it all with D to tick a "official D site made in D"
checkbox.

There are others, but those are the important ones.

Very good. That would improve the page a lot.

The code block at the top of the page, I think we don't really
need that for mobile devices with small screens. Takes up too
much space. Maybe we could just hide it and have a button or so
that says "show code".

I'd also recommend a page with simple recipes "how to open a
file" etc. In this way newbies wouldn't have to go through the

I'd love to use something like "Powered by D" for my own programs
written in D.

Jul 08 2014
"BBaz" <basile.burg gmx.com> writes:
On Friday, 18 April 2014 at 14:04:04 UTC, Aleksandar Ruzicic
wrote:
Hello,

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

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

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

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

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

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

So, what do you guys think?

-- Aleksandar

What's up with this new website design ?
Drafts looked good.

Dec 09 2014
"Martin Nowak" <code dawg.eu> writes:
 What's up with this new website design ?
Drafts looked good.

Yeah, draft looks good, but this didn't got the priority and
support it deserves.
My plan is to incrementally improve the current website until it
looks reasonable.
Already submitted a bunch of pulls.
You can see a preview here https://dlang.dawg.eu.

Dec 11 2014
"Martin Nowak" <code dawg.eu> writes:
On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:
Already submitted a bunch of pulls.

https://github.com/D-Programming-Language/dlang.org/pulls?q=is%3Apr+author%3AMartinNowak+is%3Aclosed

I'd be thankful for any help on that.
Cloning dlang.org and running make -f posix.mak should work
currently, so it's easy to try out ideas.

Dec 11 2014
=?UTF-8?B?IlRow6lv?= Bueno" <munrek gmx.com> writes:
On Thursday, 11 December 2014 at 12:22:46 UTC, Martin Nowak wrote:
What's up with this new website design ?
Drafts looked good.

Yeah, draft looks good, but this didn't got the priority and
support it deserves.