On Saturday, 19 April 2014 at 21:44:20 UTC, Nick Sabalausky wrote:
> On 4/19/2014 6:56 AM, Aleksandar Ruzicic wrote:
>> Ok here's a mockup of search concept I would like to implement:
>>
>> http://krcko.net/dlang.org/dlang-search-concept.png
>>
>> Search suggestions feature would surely require JavaScript but IMHO it
>> would be a really nice enhancement.
>>
>
> I don't know anything about the specific search-suggestion engines, but as far as looks I (mostly) really like it. Only two comments:
>
> - There should be some visual indication of the search box besides the text itself. It *looks* nice as you have it, but practically speaking it'd be a bit awkward to not be able to see the box itself.

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

> - A *lot* of search boxes on the internet these days bake the "Enter search term here" (or whatever) text into the HTML, forcing non-JS users to delete the text before they're able to 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

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.

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

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

On 4/18/2014 2:56 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> Nice initiative, but the top bar looks a lot like adobe.com . I think
> something less corporate would be more suitable. What are you trying to
> communicate? A community or a corporation?
>

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

I swear I'm not joking about this: *Real* corporate sites are:

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

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

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

On 4/18/2014 4:12 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>
> 1. visitors are likely to be familiar with one of those
> 2. they might have figured out something that works
> 3. you want to do at least what they do, but better
>

Good points.

IMO:

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

Too black-and-white.

> http://golang.org/

Too cluttered *and* too plain-white.

> https://www.dartlang.org/

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

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

> https://www.python.org/

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

On 4/19/2014 6:52 PM, Nick Sabalausky wrote:
> On 4/18/2014 4:12 PM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>
>  > https://www.python.org/
>
> This is a much better, less useless, variant of the popular
> "dartlang.org" style above. It isn't bad, but I'm not sure D really
> needs to follow this style.
>

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.

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

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.

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