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 about the technical/content side.

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.

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!

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.

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?

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?

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

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

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 read effectively.
>
> 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?

Your comments are being ignored because your comments have been
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.

On Monday, 28 July 2014 at 08:30:05 UTC, w0rp wrote:
> Your comments are being ignored because your comments have been
> 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.