On Monday, 28 July 2014 at 18:13:50 UTC, Andrei Alexandrescu wrote:
> On 7/28/14, 10:25 AM, Gary Willoughby wrote:
>> On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:
>>> "completely the wrong way to design anything.", "current design look
>>> ridiculous", "poor amateurish design", "i wish you would stop right
>>> now" - all of those comments look pretty destructive to me.
>>
>> No, that's the truth! You can sugar coat it all you want but at
>> the end of the day you have to be blunt and honest if you want
>> professional results.
>
> No, if you want professional results you have to do professional work.
>
> Andrei

Of course, but you have to be honest when things are not going well!

On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote:
> Also, and this needs to be stressed, the major part of w0rp's work so far is about the technical basis. You dismissed that as a minor detail, but it is not.

The design is *the* most important part of the web site. Period! No one cares how it works, only the user experience of the site matters. Do you think users give a hoot how facebook works?

Yes someone does have to do the 'technical stuff' behind the scenes. I do it on a daily basis but users don't care about the backend. Even if the case was made that *this* site is for engineers, the design will do. Well, systems engineers are sticking with C/C++ and app devs are sticking with Java/C# so we must make this site as accessible for everyone. We need to 'sell' D, not make it look amateurish.

In andreis Quo vadis talk i found it inspiring that he said in order to be considered a player we need to start acting like a player (paraphrasing). We need to start upping our game at this stuff!

The whole reason for this site's existence is to 'sell' D as much as possible _including_ being used as a repository of knowledge. It will sell better if the design is good, easy on the eye and easy to find what you need. The w0rp design is none of those, stop pretending it is.

Also who starts a project without designing it first? I mean honestly, why start such a major piece of work without even a vague spec? Has w0rp even asked users here what the site needs to encompass? Has the question been asked what content must exist, who needs what info and where, colour schemes, for mobile devices?  etc.

</flogging dead horse>

Am 28.07.2014 21:13, schrieb Gary Willoughby:
> On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote:
>> Also, and this needs to be stressed, the major part of w0rp's work so
>> far is about the technical basis. You dismissed that as a minor
>> detail, but it is not.
>
> The design is *the* most important part of the web site. Period! No one
> cares how it works, only the user experience of the site matters. Do you
> think users give a hoot how facebook works?

Yes, I don't try to argue against the importance of the design. The point is that it's an orthogonal feature and that it can be worked on mostly independently. You focus on the design and w0rp mostly focuses on the technical side, which is probably part of the reason why the discussion doesn't work out very well.

>
> Also who starts a project without designing it first? I mean honestly,
> why start such a major piece of work without even a vague spec? Has w0rp
> even asked users here what the site needs to encompass? Has the question
> been asked what content must exist, who needs what info and where,
> colour schemes, for mobile devices?  etc.
>
> </flogging dead horse>

He basically just took the mockup of Aleksandar Ruzicic, which was met with some optimism, and brought it to live. AFAICS that's all he really did WRT the design. The content was basically meant to stay the same as it is now*.

* Honestly, apart from some important key parts, such as the front page or the download page, it would be insane to start over and redo the contents, just for the sheer amount of work that this would mean.

On Monday, 28 July 2014 at 19:31:24 UTC, Sönke Ludwig wrote:
> Am 28.07.2014 21:13, schrieb Gary Willoughby:
>> On Monday, 28 July 2014 at 18:51:45 UTC, Sönke Ludwig wrote:
>>> Also, and this needs to be stressed, the major part of w0rp's work so
>>> far is about the technical basis. You dismissed that as a minor
>>> detail, but it is not.
>>
>> The design is *the* most important part of the web site. Period! No one
>> cares how it works, only the user experience of the site matters. Do you
>> think users give a hoot how facebook works?
>
> Yes, I don't try to argue against the importance of the design. The point is that it's an orthogonal feature and that it can be worked on mostly independently. You focus on the design and w0rp mostly focuses on the technical side, which is probably part of the reason why the discussion doesn't work out very well.
>
>>
>> Also who starts a project without designing it first? I mean honestly,
>> why start such a major piece of work without even a vague spec? Has w0rp
>> even asked users here what the site needs to encompass? Has the question
>> been asked what content must exist, who needs what info and where,
>> colour schemes, for mobile devices?  etc.
>>
>> </flogging dead horse>
>
> He basically just took the mockup of Aleksandar Ruzicic, which was met with some optimism, and brought it to live. AFAICS that's all he really did WRT the design. The content was basically meant to stay the same as it is now*.
>
> * Honestly, apart from some important key parts, such as the front page or the download page, it would be insane to start over and redo the contents, just for the sheer amount of work that this would mean.

I'm not a designer. I'm a web developer. My understanding of web design only comes from a technical and UX point of view. How CSS works, how to structure forms to make them easier to read, etc. I would love to get some help from a designer. It is as you say. I brought Aleksandar's design to life, and that's pretty much how I work during the day. I work with designers who provide mock-ups, maybe some CSS, and I make it work.

I respect Gary's opinion that you should work on design first then the technical aspects, but I believe you can work either way, probably both ways simultaneously, and achieve the same result. Architecture and design cannot function without one another. Because I have far more experience as a web developer, I've put the vast majority of my focus on putting the site together so all of the pages fit into place, because they aren't going to change a great deal from how they are now in terms of content.

When it comes to web design, I just fill in the blanks when there's no-one else to help. It's amateur work because I'm not trained as a designer. So I'm just working on what I know I can eventually get right until someone with more design experience who is willing to submit pull requests comes along.

On 7/28/14, 12:13 PM, Gary Willoughby wrote:
> On Monday, 28 July 2014 at 18:13:50 UTC, Andrei Alexandrescu wrote:
>> On 7/28/14, 10:25 AM, Gary Willoughby wrote:
>>> On Monday, 28 July 2014 at 10:38:12 UTC, Sönke Ludwig wrote:
>>>> "completely the wrong way to design anything.", "current design look
>>>> ridiculous", "poor amateurish design", "i wish you would stop right
>>>> now" - all of those comments look pretty destructive to me.
>>>
>>> No, that's the truth! You can sugar coat it all you want but at
>>> the end of the day you have to be blunt and honest if you want
>>> professional results.
>>
>> No, if you want professional results you have to do professional work.
>>
>> Andrei
>
> Of course, but you have to be honest when things are not going well!

Being honest does not entail being a jerk. -- Andrei

(edited)

On Sunday, 27 July 2014 at 16:32:15 UTC, Sönke Ludwig wrote:
> Am 27.07.2014 00:54, schrieb w0rp:
>> http://w0rp.com:8010/library/index.html
>>
>
> Since the site is running with vibe.d anyway, I'd think about using registerApiDocs() instead of generating individual HTML files. This gives much nicer URLs and also avoids potential issues with file systems that are case insensitive. See http://vibed.org/api/ for an example.

I have just been playing with this during this evening by learning from the source for the vibed.org website. I managed to integrate serving the documentation pages from /library/ just fine. This is a definite improvement. Thank you for the suggestion. At the very, very least, the URLs are cleaner this way. If this is paired with some automatic recompliation of Diet templates too, then it could be much more convenient to work with.

I set up the ddoc macros by calling the setDefaultDdocMacroFiles and setOverrideDdocMacroFiles functions, which sets them in the global scope. This could be better, but I couldn't figure out if there was a way to provide the .ddoc macros to use per Package object or similar. This doesn't matter too much right now, but it might be nice in future to provide documentation for historical D language versions too in future, like on the vibe.d site.

You can see some running examples on the site now.

http://w0rp.com:8010/library/std.parallelism/

Obviously if it stays that way, some 301 redirects will have to be set up pointing from the old URLs to the new ones. I've been setting up a few as I go already.

I'll look at playing with the style of the documentation pages some more another evening. I've had a few ideas for improvements, and I obviously still need to include syntax highlighting. Is this the library which is being used on the live site now for that?

https://code.google.com/p/google-code-prettify/

I'd be happy to go with that for now, or whatever else if anyone has any better suggestions. I used hightlight.js on my personal site to some success, but I remember thinking that the highlighting could have been better with it a few times.

http://highlightjs.org/

That's all for now.

Am 29.07.2014 00:04, schrieb w0rp:
> On Sunday, 27 July 2014 at 16:32:15 UTC, Sönke Ludwig wrote:
>> Am 27.07.2014 00:54, schrieb w0rp:
>>> http://w0rp.com:8010/library/index.html
>>>
>>
>> Since the site is running with vibe.d anyway, I'd think about using
>> registerApiDocs() instead of generating individual HTML files. This
>> gives much nicer URLs and also avoids potential issues with file
>> systems that are case insensitive. See http://vibed.org/api/ for an
>> example.
>
> I have just been playing with this during this evening by learning from
> the source for the vibed.org website. I managed to integrate serving the
> documentation pages from /library/ just fine. This is a definite
> improvement. Thank you for the suggestion. At the very, very least, the
> URLs are cleaner this way. If this is paired with some automatic
> recompliation of Diet templates too, then it could be much more
> convenient to work with.
>
> I set up the ddoc macros by calling the setDefaultDdocMacroFiles and
> setOverrideDdocMacroFiles functions, which sets them in the global
> scope. This could be better, but I couldn't figure out if there was a
> way to provide the .ddoc macros to use per Package object or similar.
> This doesn't matter too much right now, but it might be nice in future
> to provide documentation for historical D language versions too in
> future, like on the vibe.d site.

The DocGroupContext class currently returns null for its overrideMacroDefinitions and defaultMacroDefinitions properties. This would just have to be extended so that it becomes possible to inject custom values. I've added a ticket for that:
https://github.com/rejectedsoftware/ddox/issues/51

>
> You can see some running examples on the site now.
>
> http://w0rp.com:8010/library/std.parallelism/
>
> Obviously if it stays that way, some 301 redirects will have to be set
> up pointing from the old URLs to the new ones. I've been setting up a
> few as I go already.

There is also a pending change for the current documentation that changes the current link style (balancedParens.html) to lowercase underscore notation (balanced_parens.html), so there will be a bunch of redirects already. One issue with this is that the new style will sometimes have ambiguous redirects to the canonical style (balancedParens) because it removes the case information, but I don't really see a way around that.

>
> I'll look at playing with the style of the documentation pages some more
> another evening. I've had a few ideas for improvements, and I obviously
> still need to include syntax highlighting. Is this the library which is
> being used on the live site now for that?
>
> https://code.google.com/p/google-code-prettify/

That plus some modifications to add D support. But my plan was to use server side highlighting using Brian Schott's lexer in the future.

On Monday, 28 July 2014 at 22:38:10 UTC, Sönke Ludwig wrote:
>> I'll look at playing with the style of the documentation pages some more
>> another evening. I've had a few ideas for improvements, and I obviously
>> still need to include syntax highlighting. Is this the library which is
>> being used on the live site now for that?
>>
>> https://code.google.com/p/google-code-prettify/
>
> That plus some modifications to add D support. But my plan was to use server side highlighting using Brian Schott's lexer in the future.

That's probably a good call. Were you thinking of discovering <code> blocks in pages and running the lexer on them to produce the formatted output?

On Monday, 28 July 2014 at 11:35:21 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 28 July 2014 at 11:16:39 UTC, Dicebot wrote:
>> going and getting stuff done - same principle apply here. If you have professional web development experience that may help here - start helping somehow.
>
> You need to define and agree on a process first. If not you will have to redo the site 10 times before getting to the end result. Then you will have to redo it whenever someone decides to add a feature that contradicts the design/layout, because they assumed that it would be easy to add later.
>
> What are the key requirements?
>
> What is the primary user base (front page, doc pages etc)
>
> What are the main target platforms?
>
> What is the intermediate format?
>
> What is the primary use scenarios?
>
> What are the key future functionality that it has to accomodate?
>
> What nice-to-haves can we cut in order to reduce work?
>
> Who gets the final word when you cannot get a decision?
>
> etc.

It has never worked that way with D development process and I don't see it happening without any major structural changes. Pretty much everything that does not come from Walter or Andrei is decentralized anarchy-driven development - you do something, show it to community, see results.

All these questions are nonsense crap without someone actually willing to do the work. Such attitude may insult professionals but there are no hired professionals working here.

On Monday, 28 July 2014 at 17:23:37 UTC, Gary Willoughby wrote:
> It is frustrating because i want this to be done well as it could really help D take off.

Doing it on LAMP won't help D to take off. In a sense, you don't even criticize this work, as a professional web designer, you can provide a constructive feedback, if you assess, whether the D web stack is ready for use by a web designer, whether SSI is done right, what features are missing or confusing, is it easy do setup a development environment. If LAMP is better, you can report the problems.

> https://www.dartlang.org/

Actually bad scrolling UX because of the floating panel.

On Monday, 28 July 2014 at 19:13:12 UTC, Gary Willoughby wrote:
> Also who starts a project without designing it first? I mean honestly, why start such a major piece of work without even a vague spec? Has w0rp even asked users here what the site needs to encompass? Has the question been asked what content must exist, who needs what info and where, colour schemes, for mobile devices?  etc.

Current web site has certain purely technical issues that switching to more dynamic vibe.d based implementation will help to deal with. Even if design doesn't change a single bit it is a welcome and much needed change. Because of that starting with technical stuff makes perfect sense.

Stuff you care about is marketing stuff. It is only partially relevant to informational usability concerns that are of primary interest to existing language users.