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.
