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

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.

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

On 4/19/2014 4:16 AM, Aleksandar Ruzicic wrote:
>
> I'm slightly against autofocus on search field, as I am one of people
> who use Backspace to navigate to previous page and I'm always frustrated
> when I hit Backspace on Google search results page and it's not taking
> me to previous page.
> But if majority thinks that autofocus on search is a good thing (I also
> think that not many people use Backspace as a means of navigation) than
> I would make it like that (and if there would be that little preferences
> page/popup this option is something that can go there together with
> justification settings).
>

I use a browser extension to disable backspace navigation since I get annoyed when I try to type something and the browser decides to navigate to a different page ;).

That said, I don't really have an preference on autofocus vs not-autofocus.

> Download sites do that, so does sites that sell software. I think that
> dlang.org should focus on promoting D as a language, and compiler
> implementations should not be in spotlight.
> Also I think that having Download in top-nav as a first option is
> prominent enough. I've put what I think are the most important sections
> in top-nav bar (other navigation items should go to context-sensitive
> sidebar).

I strongly believe that a prominent link the the downloads page is one of the *most* important things to have in the top-nav bar. We may not be selling it for $$, but we are "selling" people on it. I know I get annoyed when I'm on some software's website, want to download it, and have to looking around for it because I don't see a download link in the typical download link location (top nav-bar). We want people to download it and try it, so it's good to match people's expectations here.

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

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.

On Saturday, 19 April 2014 at 22:38:31 UTC, Nick Sabalausky wrote:
> I had a brief thought of that too, but I quickly dismissed it because it really *isn't* corporate-looking...

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

Push github links, tutorial links, download and latest activity with member names.

 I also find the big highly saturated logo in desaturated context annoying. It draws too much attention and makes the design unbalanced. That's what you do for branding. Put that saturation on where you want people to look. The download/start tour/etc buttons.

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

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

Just to stating some basic observations to avoid noise.

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

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

3. The current D population is not your primary target. Your primary target is people who stumble over dlang.org while searching on Google and spend 2 seconds glancing over your stuff.

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

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

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.

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