[OT] Re: Redesign of dlang.org

[w0rp via Digitalmars-d]

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

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.