Jump to content
ryan

New post: New PW website ready

Recommended Posts

2 hours ago, MoritzLost said:

Another thing, the main content on the documentation pages is a bit too wide for my taste, longer texts are harder too read since the lines are too long. Currently the #content-body sits at about 70rem, I'd reduce that to maybe 45~50 rem and center it between the sidebars. See screenshots, feels much easier on the eyes to me.

+1, forgot to mention this one. WCAG AAA requires that line length is never more than 80 characters, but depending on the source comfortable range can be around 80..100 characters, and sometimes as high as 120. Anything above that is way too long considering readability, and I'd recommend not going past the 100 character (or glyph) mark.

  • Like 2

Share this post


Link to post
Share on other sites
On 1/5/2019 at 11:41 AM, adrian said:

I don't like the pages that put the title next to the PW logo in the header, especially given that not all pages do this - I know it depends on what level page you are on (although not entirely), but I still find it a little confusing.

Agree with this. The logotype should stay top left on all pages at all times, it's a design pattern that users are used to and expect.

  • Like 2

Share this post


Link to post
Share on other sites
5 hours ago, MoritzLost said:

Only the pure white headlines pass AA level, AAA fails completely

Could we maybe deal with this with an optional high-contrast mode? I know accessibility is important but aesthetics, depth and some degree of subtlety are also important. If we insist that all text everywhere has a contrast ratio of 7:1 to cater to the most visually impaired visitors then we give up things like using reduced opacity to differentiate primary/active text versus secondary/deactivated text, and must largely abandon the brand colour as a background. Also its arguable that a high-contrast design is harsher on the eye to the majority of visitors who are not visually impaired.

 

5 hours ago, MoritzLost said:

Another thing, the main content on the documentation pages is a bit too wide for my taste, longer texts are harder too read since the lines are too long.

This issue is improved by setting a max-width for the layout. Personally I'd rather see an increased text size for wider viewports than having the main text column floating in the middle, with looks off to me. And if we change to a different font that is less condensed and has a bit more letterspacing built into it then we can achieve a comfortable line length without compromising the aesthetics. Here is my Work Sans variation with the font-size bumped up a little -  line length is at a comfortable 100 characters, matching @teppo's suggestion. The main content column could have a slightly reduced max-width on wide viewports if we wanted to bring the line length down a little further.

https://sitemod.robin.nz/render/?url=https%3A%2F%2Fprocesswire.com%2Fnewsite%2Fstore%2Fpro-fields%2Frepeater-matrix%2F&css=https%3A%2F%2Fsitemod.robin.nz%2Fnew-pw%2Fmod-2.css

2019-01-07_120224.thumb.png.43fda651074d15d2adf3140b9d1603a9.png

  • Like 2

Share this post


Link to post
Share on other sites
44 minutes ago, Robin S said:

Could we maybe deal with this with an optional high-contrast mode?

github clrux a11y-toolbar maybe?  or this link: https://github.com/downzer0/a11y-toolbar

 

Spoiler

a11y-toolbar.gif.f53d955441d823d5bf57753c8fbe1b8b.gif

 

 

Edited by horst
corrected 404 link
  • Like 3

Share this post


Link to post
Share on other sites

I must say that i am very much in love with where the new site is going and specificly the Document section.

And finaly a section that explains the "Markup Regions" 🙂
Enjoying that section very much because i have planned for a long time to move over to using Markup Regions, but with the information scatterd all over the forums and the old site it was hard to get a complete grasp on the inner workings.

Now i think with the new Documents section its pretty crystal clear how it works.

Thank You Ryan and everyone working hard on the new site. Looking forward to the release when its finished.

  • Like 2

Share this post


Link to post
Share on other sites

Great work Ryan, thank you!

On 1/5/2019 at 1:58 PM, MrSnoozles said:

Edit: It's been said in different topics already, but not really highlighted that much here. Like Bernhard,  I think "headless" is a powerful marketing buzzword these days that could be used on the homepage. 🙂

I fully agree with this. Our main use of Processwire is as a headless CMS / CMF for Single Page Applications. As a possible future user I would be very interested in learning about how PW can be used in this way. I would look for that on the 'Output' page (https://processwire.com/newsite/docs/front-end/output/). 

A simple JSON API example, without the use of any external modules, would suffice here I think. 

  • Like 5

Share this post


Link to post
Share on other sites

Ryan - I think this is really important!!!

Earlier (https://processwire.com/talk/topic/20596-new-post-new-pw-website-ready/?do=findComment&comment=178332) I mentioned all the different ways to get $page that are listed on the variables page - turns out there is of course another $wire->pages which you don't mention there, but you do mention on the bootstrap page. I am not sure how to best clean this all up, but I think it makes things very confusing.

Perhaps the entire website should stick with "$page" etc in all examples and wording, but then there is one dedicated page that explains what version can be used when/where and the pros and cons of each.

  • Like 13

Share this post


Link to post
Share on other sites
6 hours ago, eelkenet said:

I fully agree with this. Our main use of Processwire is as a headless CMS / CMF for Single Page Applications. As a possible future user I would be very interested in learning about how PW can be used in this way.

On a sidenote: Just scanned this article today and truly lolled reading this comment

 

  • Like 4

Share this post


Link to post
Share on other sites

Ryan,

A few more things:

1. Any reason why on this page: http://processwire.com/newsite/docs/start/install/upgrade/ you link to the Github repo for your PWUpgrades module, rather than the entry in the modules directory? Actually, I think this module should be promoted much more - I know you have security concerns with it on shared hosting, but I feel like more often than not PW devs will have a VPS or similar and can safely make use of this module - it's such a great timesaver and a nice plus for PW.

2. There is a typo on: http://processwire.com/newsite/docs/more/lazy-cron/ - note the capitalized 'O' in modules

Quote

This is a core module included with ProcessWire 2.1+. Go to Admin > MOdules and click "check for new modules".

3. Talking about those instructions - do we even have the "check for new modules" button/link these days? I also don't think you should bother mentioning PW 2.1 on the new site, so I think the instructions should say to go to the Core tab, find the module and click the install button.

4. On http://processwire.com/newsite/docs/modules/intro/ I would have thought that the main method for installing a module would be to enter the class name as listed in the modules directory, but you still primarily mention uploading files to site/modules. Getting OT, but is it time to have an AJAX driven autocomplete field for installing modules directly from the modules page?

5. Do you think it's a good idea listing those two CMSCritic reviews here: http://processwire.com/newsite/about/processwire-reviews/ - given that they went back and forward so many times and are now on WP I am not sure they are good arguments for PW.

6. Design / color choice is not my forte, but I find the grey boxes look dirty, eg:

image.thumb.png.e9c990b9515cd93945011eade79b5302.png

7. Also, on the design front - I have already mentioned the blog "boxes", but the other thing that bothers me about that page is the blue background - I think it's too overpowering and completely out of character with the rest of the site.

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Just wanted to mention, that the blue is the default primary background color of UIkit. Probably it will change and it wasn‘t chosen on purpose. 😉

Share this post


Link to post
Share on other sites

Hey guys, wow, thanks for all the feedback and testing! 

I’ve pushed an update to the pre-launch staging site that fixes most of the glitches that have been brought up. There were a couple that I wasn’t able to duplicate, so I’ve quoted those below along with more questions.

There’s a lot of subjective stuff in this thread as well, which is of course great for conversation, but please don’t feel sad if I don’t implement these suggestions at this stage. The focus now is purely on just making sure that what’s present works as it should (working out any bugs), and not trying to re-do or rewrite anything prior to launch. So if you don’t like the blog or some color or some other part, that’s fine—I hear you and am keeping notes. But I’ve first got to make myself happy with it first before launching it, so that’s where it’s at. Over time I’m sure much will change, and of course all suggestions are appreciated, but for now bug fixes are the focus, and we’ll work on other stuff later.

Regarding accessibility stuff, I have implemented several of the suggestions here like some of the items Teppo mentioned. Though should clarify there isn’t a specific goal of tailoring the site for visually impaired people at this stage.  I don’t think that’s a large part of our audience at present, and so I want to focus time in the short term towards optimizing towards the traffic that the site will be serving. But please keep these suggestions coming because this is still very useful and we’ll get to more of this soon.

One thing that has come up multiple times in this thread has to do with fonts and/or colors. We may very well change the primary color at some point, but not until the Modules, Directory and Forum sites are updated for the new design. The whole point of the current color scheme is to maintain some relation to the existing sites, since it may be weeks before those other ones are updated. But experimenting with colors is still I good idea. 

You can change the color of the entire site by using a URL with a “?color=<hexcode>” on any URL in the site. Once you do that, the color will be retained on any links you click on, so you can browse the site with your selected primary color. Here’s an example that changes all the blue to the PW pinkish/red color (try not to laugh!):

https://processwire.com/newsite/?color=e83561 

Replace that e83561 in the URL above with any hex color code to experiment. If you come up with anything you like, paste in the link so we can all see it. 

Fonts are one thing that we might have to change before launch. As Horst mentioned, the current font renders really poorly on his computer, which means it might be the same for other people (though have not yet had confirmation from anyone else). Plus a couple of you have mentioned you don’t like the font, so I’m open to changing it (though admittedly I really like the current font). I’ve set it up so that you can experiment with different fonts for the site by doing the same thing that you did for the color URL above, but with “font=name”, replacing “name” with the name of the font. It can be any one of these below. The ones near the top are ones I kind of like, though no real order other than that. 

https://processwire.com/newsite/?font=rubik
https://processwire.com/newsite/?font=barlow
https://processwire.com/newsite/?font=encode (no italic)
https://processwire.com/newsite/?font=khula (no italic)
https://processwire.com/newsite/?font=mada (no italic)
https://processwire.com/newsite/?font=montserrat
https://processwire.com/newsite/?font=nunito
https://processwire.com/newsite/?font=palanquin (no italic)
https://processwire.com/newsite/?font=raleway
https://processwire.com/newsite/?font=source
https://processwire.com/newsite/?font=muli
https://processwire.com/newsite/?font=fira
https://processwire.com/newsite/?font=hindm (no italic)
https://processwire.com/newsite/?font=hinds (no italic)
https://processwire.com/newsite/?font=ibm
https://processwire.com/newsite/?font=lato
https://processwire.com/newsite/?font=open
https://processwire.com/newsite/?font=roboto
https://processwire.com/newsite/?font=sarabun
https://processwire.com/newsite/?font=exo2
https://processwire.com/newsite/?font=titillium
https://processwire.com/newsite/?font=noto
https://processwire.com/newsite/?font=cairo (no italic)
https://processwire.com/newsite/?font=saira (no litalic)
https://processwire.com/newsite/?font=heebo (no italic)

As some of you might now, I got my first new computer since 2013 a little more than a month ago, and it's an iMac 27" (though a used one), so that's kind of why I wanted to get it on the homepage. I know it's not the newest looking computer, etc., but I really wanted something more than just a browser frame. Yes the screenshot jpegs that appear in it a low quality jpegs (quality=10). My eyes aren't so good and I'm not seeing the compression, but sounds like some of you are. I may redo those at a higher quality before launch. Though the way I see it, this whole iMac with screenshots thing is probably temporary anyway. I really like what @Jonathan Lahijani is doing with that video and am thinking that will be a much more useful fit for the homepage longer term. 

Quote

The dropdown menu on the right side is cut off (see screenshot)

@jmartsch and @gmclelland

I can’t seem to duplicate this one (also Chrome). Tried numerous widths, including the narrower width like shown in the screenshot too. That dropdown is always opening to the left for me. The screenshot shows it opening to the right. Just wondering if anyone else is seeing it and if so, do you know of any adjustments that would correct it? 

Quote

Only one thing I want to show you know: Unfortunately the fonts render very bad on my machine, win7 firefox 64. 

@horst

This is the biggest concern I’ve come across here, as those fonts definitely look terrible in the screenshot you linked, and we definitely don’t want anyone to see them look like that. Is it an issue with this particular font, or do you observe Google Fonts in general rendering like this? Is this a known issue if you Google around, or is it just something you are observing on your computer? Do any of the new fonts render properly on your computer?

Is anyone else seeing them render like this? I’m wondering if the issue is isolated to a particular platform/browser, or what it might be isolated too. So far nobody else has reported this, but if you are seeing it please speak up. 

  • Like 5

Share this post


Link to post
Share on other sites
Quote

 

Just wanted to mention, that the blue is the default primary background color of UIkit. Probably it will change and it wasn‘t chose n on purpose.

 

This is not the case. The blue came from a color picker on the masthead of the current PW site. Though the current site uses a gradient, while the new site does not. 

Share this post


Link to post
Share on other sites

Thanks for adding the font/colour variations to the preview Ryan.

26 minutes ago, ryan said:

I’ve set it up so that you can experiment with different fonts for the site by doing the same thing that you did for the color URL above, but with “font=name”, replacing “name” with the name of the font. It can be any one of these below.

I think the typefaces without italic styles need to be taken off the table as body font candidates (unless we're never going to use italicised type on the site). It's just too great a typographic sin to have the browser slant the roman styles and it will make us look like amateurs.

That would rule out the following from the list:

  • Encode
  • Khula
  • Mada
  • Palanquin
  • Hind M / Hind S (the latin characters are the same in those faces - the difference is in the Tamil characters)
  • Cairo
  • Saira
  • Heebo

Can we get Work Sans added to the list? I think it's one of the classiest typefaces available as open-source and it has the distinction of being less familiar/thrashed/played-out than the usual suspects like Montserrat, Lato, Open Sans, etc. Note that italic styles do exist for Work Sans, they just haven't been merged into Google Fonts yet.

Share this post


Link to post
Share on other sites

Just a note about fonts. Maybe we should consider fonts with the Cyrillic glyphs support? In the longer term, there probably maybe some messages on the forum or even parts of documentation translation in Ukrainian or Russian languages. Without Cyrillic glyphs, this parts will fallback to another font and it will look not consistent with other parts. 

  • Like 4

Share this post


Link to post
Share on other sites
40 minutes ago, ryan said:

 

@jmartsch and @gmclelland

I can’t seem to duplicate this one (also Chrome). Tried numerous widths, including the narrower width like shown in the screenshot too. That dropdown is always opening to the left for me. The screenshot shows it opening to the right. Just wondering if anyone else is seeing it and if so, do you know of any adjustments that would correct it?

I'm seeing this too with some fonts.

It think it depends on actual font widths.

Try to set some zoom (e.g 125%) in your Browser and you will probably see it too.

 

Share this post


Link to post
Share on other sites
42 minutes ago, ryan said:

Regarding accessibility stuff, I have implemented several of the suggestions here like some of the items Teppo mentioned. Though should clarify there isn’t a specific goal of tailoring the site for visually impaired people at this stage.

Thanks – I can see definite improvements already, and we can surely keep improving things after the initial launch as well! Regarding the target group I get what you're saying, but it's good to keep in mind that improved accessibility actually benefits us all – it's not (just) about catering for users with disabilities 🙂

"While accessibility focuses on people with disabilities, many accessibility requirements also improve usability for everyone. Accessibility especially benefits people without disabilities who are in limiting situations, such as using the web on a mobile phone when visual attention is elsewhere, in bright sunlight, in a dark room, in a quiet environment, in a noisy environment, and in an emergency." (W3C WAI)

42 minutes ago, ryan said:

Yes the screenshot jpegs that appear in it a low quality jpegs (quality=10). My eyes aren't so good and I'm not seeing the compression, but sounds like some of you are. I may redo those at a higher quality before launch.

My eyesight is way below average, and I can see a lot of artefacts and other signs of low quality in there. Just checking, but do you have a retina screen? Could be somehow related to resolution as well – I've got a 15" MacBook Pro with resolution set to "scaled" and "more space" set to the maximum value.

  • Thanks 1

Share this post


Link to post
Share on other sites
38 minutes ago, ryan said:

I can’t seem to duplicate this one (also Chrome). Tried numerous widths, including the narrower width like shown in the screenshot too. That dropdown is always opening to the left for me. The screenshot shows it opening to the right. Just wondering if anyone else is seeing it and if so, do you know of any adjustments that would correct it? 

I see the problem with Firefox (Mac), but not in Chrome.

Share this post


Link to post
Share on other sites
36 minutes ago, ryan said:

I can’t seem to duplicate this one (also Chrome). Tried numerous widths, including the narrower width like shown in the screenshot too. That dropdown is always opening to the left for me. The screenshot shows it opening to the right. Just wondering if anyone else is seeing it and if so, do you know of any adjustments that would correct it? 

I see it because I had my Chrome browser zoomed to 110%.  I think it might be caused by the overflow issue that @Jonathan Lahijani mentioned at 

 

Share this post


Link to post
Share on other sites

See pictures.

Same browser Chrome. Once 100% and once 125% zoom.

pwzoom100.png

pwzoom125.png

Share this post


Link to post
Share on other sites
1 hour ago, ryan said:

This is not the case. The blue came from a color picker on the masthead of the current PW site. Though the current site uses a gradient, while the new site does not. 

My bad, thank you for the clarification.

Share this post


Link to post
Share on other sites

@ryan Regarding the fonts rendering. There are three out of 25 that also look ugly on my machine and FF64: sarabun, lato, titillium. But not at such a high scale ugly compared to the initial font. And five out of the above font list renders very sharp and clear: rubik, nunito, ibm, roboto and open sans, of course.

Hope that helps a bit.

  • Like 2

Share this post


Link to post
Share on other sites

Couple of bugs:


On https://processwire.com/newsite/docs/start/install/upgrade/ 
Maybe mention @adrian ModuleToolkit module for bulk module upgrades?

 

  • Like 1

Share this post


Link to post
Share on other sites

@Robin S Here's Work Sans:

https://processwire.com/newsite/?font=work

This is one of those fonts that I do agree with you is very nice, but it seems like it works in some places and not others. I think it's the width combined with some of the details that is giving me trouble, especially at body copy sizes. Or maybe it could be that it's just so different that I'm not used to it. 

Quote

 

My eyesight is way below average, and I can see a lot of artefacts and other signs of low quality in there. Just checking, but do you have a retina screen? Could be somehow related to resolution as well – I've got a 15" MacBook Pro with resolution set to "scaled" and "more space" set to the maximum value.

 

@teppo I am using a retina screens, both on my aging MBP and 27 iMac. However, my eyes are not so good, so I simply can't see anything if I use the scaled down resolutions. 🙂 I have to use the default res (2560x1440 on the iMac). Not seeing the artifacts myself, but I know they are there, as I definitely saw them when I exported them in Photoshop. But the scaling them to 50% down (for hidpi) must have taken care of that. If using screen at native resolution (non-hidpi) I can see how the artifacts would show. I'll try re-exporting these. Making them PNGs doubles the size, but I think that's okay because I'm actually lazy loading these 1-by-1 as they display, so it's not slowing the initial page load. 

@horst thanks for reporting back on the fonts! Good to know some of them render well.

Good to hear about the 110% thing being the cause of the dropdown issue. Though I have no idea how to fix that. I might have to switch up the order so that one of the items without a dropdown displays last. 

 

  • Like 3

Share this post


Link to post
Share on other sites

Little thing, but #content2 seems to be (at least partially) responsible for the unwanted horizontal scrollbar at widths below 1600px.
Specifically, if margin-right: -40px; is commented out  in .blog-posts,  the unwanted scrollbar disappears, consistent with it being overwritten to 0 at the 1600px breakpoint.

  • Like 1

Share this post


Link to post
Share on other sites
1 minute ago, ryan said:

Good to hear about the 110% thing being the cause of the dropdown issue.

Just in case you missed my comment above - it's an issue with Firefox even at 100%

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...