Ponder holding iPhone X in landscape.
As the safe area seems to be symmetrical, the inset of the safe area is as big on the left side as on the right side, regardless which side the notch is on.
Assume that we would want to have the safe area stretch further to the screen edge on the side where the notch is not on. Anyone got a good approach for that? I assume that we would want something that works with autolayout.
Here the notch is on the left side. We would like to have the margin on the other side smaller, because it feels like we could display more contents there.
While it's possible to do this, Apple advises that you don't do it in their Human Interface Guidelines:
Inset essential content to prevent clipping. In general, content
should be centered and symmetrically inset so it looks great in any
orientation and isn't clipped by corners or the device's sensor
housing, or obscured by the indicator for accessing the Home screen.
For best results, use standard, system-provided interface elements and
Auto Layout to construct your interface. All apps should adhere to the
safe area and layout margins defined by UIKit, which ensure
appropriate insetting based on the device and context. The safe area
also prevents content from underlapping the status bar, navigation
bar, toolbar, and tab bar.
That said - I totally understand wanting to use that extra space!
In trying to understand this part of the HIG, let's put it this way: if you have a game that you're watching in landscape, the controls should be symmetrical, so that whether the user is holding the game in landscapeLeft or landscapeRight, the button is inset by the same amount. If you implement your controls asymmetrically, then the user's muscle memory won't match in one orientation vs another.
You can hear Mike Stern (Design Evangelist at Apple) talk through this concept in the WWDC video from Fall 2017 title "Designing for iPhone X". (This link has a timestamp where Mike discusses landscape symmetry in detail.)
Related
I was under the impression, that the units vh and vw deal with mobile browser zooming in, but apparently that's not the case and I think I am beginning to understand why. Zooming in does not change the viewport at all, but merely shows the user only a part of the viewport, despite the name viewport. Basically there is a difference between what you can see and the viewport. I don't know if distinguishing those two really makes sense, but that's how it seems to be.
The question is: How else do I "react" in my stylesheet to zoom changes?
For example, I have some html element with a width and it fits on the screen of a mobile phone. Now the user zooms in (doing that two finger gesture, moving the fingers away from each other). The size of the element should stay the same relative to what the user sees, but text should get bigger, because it might be the reason why the user zooms in. Maybe they couldn't read it before or want a link to be bigger, so that they can click more easily on it.
How would I do such a thing?
I've read about #viewport stuff, but it's not really supported yet and also poses the question, when to use which viewport size, how to make it as fluent as when you use vh and vw on a destop browser? Simple limiting "up to so and so much px of width" won't do. Defining a mathematical function for how much the element changes its size relative to what one can see and how much the text size changes would be great, but is probably not possible to have.
On mobile devices, the text-size-adjust property allows Web authors to control if and how the text-inflating algorithm is applied to the textual content of the element it is applied to.
As this property is non-standard, it must be used prefixed: -moz-text-size-adjust, -webkit-text-size-adjust, and -ms-text-size-adjust.
Browsers on smartphones don't display web pages using the same algorithms as browsers rendering web pages on desktop machines. Instead of laying out the web page at the width of the device screen, they lay it out using a viewport that is much wider than the device screen, usually of 800 or 1000 pixels wide. One of two possible methods is used to map back to the original device coordinates: either a smaller window is then used to display on the device screen only part of what is actually being rendered, or the viewport is stretched to the size of the device.
Its highly experimental though
I am working on a site that gradually changes opacity on page text from 0 at the bottom of the viewer to fully visible by the time the user scroll has positioned the text mid-view. The text is able to be read by a screen reader. It also would meet contrast requirements once it reaches full opacity. Can anyone tell me if this violates WCAG 2.0 standards?
Sincerely, this is a very good question.
There is visible text on screen which is not readable and this requires the user to scroll in order to give it full opacity.
From a "visually" point of view, this is not choking. Despite that you are reducing vertical readable area, as long as you can zoom up to 200%, and still read upper lines, this might be acceptable depending on the size of the occulted area from a WCAG view...
The fact that this text is readable by a screenreader is a good point among a lot of accessibility considerations.
If you consider some visual or mental disabilities, this might be hard to understand. For instance, an old person with a glaucoma can not perceive that the effect of gradual change of opacity is not something caused by the disease. Requiring the text they read to be at the centre of the screen is not something evident. Do we move a book from up to down each time we read a line of it?
This also requires more scrolling, so it will ask more physical efforts to read. One click is not very much effort for many people, but clicking on the small arrow of a scrollbar is fairly hard for the elder generation (not everyone uses keyboard).
TL;DR: This might be considered valid from a WCAG point of view, but this does not help ergonomics
I think that this would violate the Contrast (1.4.3) criterion on the WCAG 2.0. Your text provides sighted users with a visual cue that color-blind users may not be able to see. It's possible that the text may be unperceivable to color-blind users until the minimum contrast requirement is reached.
The only exceptions to the color contrast criterion are if your text is incidental (i.e. decorative or invisible to users in general). I don't think this text could be considered incidental, however, since it sounds like it is the body content of the page and it remains (at least to some degree) visible to fully sighted users without requiring them to scroll through the content.
I mainly work with a laptop. My question is if I should worry about the fact that the same colors look darker on top such as the menu bar but lighter on the bottom such as the footer. The colors are the same, rgb(60,60,60).
Is it because my screen is cheap or is it due to my choice of colors? On my HP envy or tablets etc it looks great.
See this link
There are just too many reasons to explain why screens color things differently.
Some of these include:
rgb color settings
age of screen (older screens may 'burnout', or 'not be vibrant')
screen type
viewing angle
type of screen (LED,LCD,etc).
This is the reason the likes of most 'new' games actually ensure you calibrate your screen before playing them ("Please alter screen until logo is barely visible") - this is up to the user/client to decide, not you as a developer (although this 'setting' could be useful, but possibly overkill ;)).
Even with using the same make and model of screen, there may/will still be differences in colouring.
It's just a fact of computing I'm afraid.
So, the bottom line is, no, I wouldn't worry about it. the best thing you can do is ensure you use a good color scheme (not similar colours), and this should allow even the oldest of screens to work happily enough with your websites/etc.
I am building a learning product(in flex/flash) that will get used both by an individual on her desktop, and also by a instructor in a large room. The challenge is rooms, where this will be used, tend to be quite large- as big as 80-90 people and seating far from screen
I am not sure a single font size(12-14 font) will work for all- currently I have built it for "personal use" to use real-estate best and am hoping tweak slightly for "projector mode"- plan is to allow user to selectively pick and magnify various sections of the screen- is this a model that is done elsewhere- what are the best practices here?
Any thoughts on how to program for this?
You should keep it down to only a few short lines of text and an image/video if you're presenting this on a projector. The fact is, 12-14px fonts are much too small for that application - you should use 24px and up. Consider that projectors will typically have lower resolutions than monitors and your display will be scaled down somehow, which usually renders small / thin text unreadable. You might want to design for a 1024x768 projector, and let your interface scale so the users see the same display (same proportions and positioning) on their computer - I caution you that if you must use raster images, use high enough resolution images that they don't see a pixelated mess on their high res screens.
A useful article on slide design can be found at http://www.thinkoutsidetheslide.com/articles/select_and_use_fonts.htm and you can probably use the default templates in Powerpoint as a starting point for your layout. Don't shoehorn too much information into one screen!
I am not a designer but I am trying to learn some basic principles of web-design. A basic question I am wondering about is whether or not to center a page's content on the screen. Maybe you are familiar with A List Apart. They provide a good number of articles on web-design. What strikes me as odd is their own design. The whole page is to the left of my 24 inch screen (about 11 inch to the right is completely blank). What are the pros and cons of centered vs not centered?
Thanks in advance!
An average user of an all-purpose web site is likely to have 1280*1024+ resolution. If you also support 1024*768 (i.e. max 960px width) and put your content to the left side of the screen, users at 1280*1024 would just have to turn their head a little bit but think of a user at 1920*1080, who would need to actually change seating position to clearly read the content, which would be occupying just the left half of the screen.
Apart from those, I don't see any technical advantage or disadvantage of floating to the left.
People read left justified text faster than centered text.
A List Apart has a content column that's a bit wide for comfortable reading on a large screen. It's probably the correct size for a smart phone. People are more comfortable reading columns of text, like a newspaper, than if the text runs across the screen.
If you want to center the entire layout, you can, but it's easier for people to size their browser to fit a left justified layout. Some people may have 3 or 4 browser windows showing on their wide screens at the same time. I have two monitors on my work and home computer, and sometimes I'll have 3 browser windows showing at the same time.