An em space is the width of the letter m. IIRC, a normal space in most proportional fonts is closer to the letter n.
It has always been my understanding that historically, typographers tended to prefer em spaces between sentences (vs. after intra-sentence punctuation like 'Mr.' or a comma). And so, once typewriters with their fixed-width fonts came out¹, people used a double-space at the end of a sentence to approximate an em space.
The frustrating thing, typographically-speaking, is that the HTML approach doesn't map to the manually-typeset process, either, since it doesn't have any semantic knowledge about "end of sentence" vs. "random intra-sentence punctuation" and thus treats them all the same.
(Note that this is also where we get em dashes and en dashes from. And just like em spaces and en spaces, an em dash is transliterated to '--' in fixed-width fonts.)
¹ For all I know, the double-space trick was used with fixed-width letterpress before the advent of typewriters. The problem seems to have more to do with fixed-width than with typewriters.
The thing is that the period on a typewriter will usually be aligned towards the previous letter, so a "period space" sequence on a typewriter will have nearly the same amount of space as would be seen in a "period space space" sequence on a software word processor when not using a fixed-width font. In essence, this furthers the idea that the double space is an emulation of the output of a typewriter, rather than supporting the idea that it's influenced by typesetting (where in the past the space between words might have been 1/3 or 2/3 the width of the space after a period, if no other space was added throughout the sentence for alignment).
For the most part, the article justifies simply blaming publishers for becoming lazy, though it seems to me that they choice of spacing around sentences is largely determined by the market for which something is being published, and most publishers would have invested at some point in a decent lexer that can handle enough of the burden of finding the ends of sentences to allow the process to be largely hands-off (and allow the appearance of the output to change fairly easily if they want to print a special or mass-market edition later).
It's conceptually a single space, but the difference between 'two spaces' and 'a space twice as wide as normal spaces' isn't very important. Since lines won't wrap mid-space-block, it's effectively an encoding issue.
Typos on page 2: “At one interview, he had to hung up the phone because the journalist couldn’t understand the difficult topics involved … If he don’t get it, will he be sad about it?”
Regardless, awesome idea. I plan on reading it through.
Thank You. I am Swedish, so I might have made some silly errors. That's why I released it through Leanpub, so don't be afraid of complaining. Or as Musk himself said: "Don't tell me what you like, tell me what you don't like."
I'm an app developer looking to supplement my meager income. I've been making apps since day one of the App Store and have always focused on the front-end design.
People gravitate towards icons and screenshots; why not have the best ones in the store?
Design doesn't stop at the visuals, though. I work with you to make a sensible hierarchy and layout, keeping your users happy and recommending you. I know backend code, so everything I design is possible.
Email me a link to your app; I'd happily give you some thoughts.
I'm a mobile app UX designer and consultant available for all platforms: iOS (iPhone & iPad), Android, & Windows Phone. If you want to start (or re-finish) an app, give me a call first.
I know the design guidelines just as well as the code underneath. Everything I create comes from someone who's gotten his hands dirty with development on multiple occasions.
Your screenshots don't have to be literal screenshots. At first glance, there doesn't seem to be anything special about your app. Its main feature is un-advertised!
I would suggest some sort of transitional photo. Show the sloppy drawing fading into the crisp flowchart. Maybe a little text on the image. "Draw flow charts in seconds!".
I second this. Use some of the frawing diagrams from the help view to show how shapes are created (I'd show at least a box and an arrow on one screenshot). It will also reduce first-use frustration trying to create shapes.
This works, but setting the cornerRadius property kills performance. It's preferable to overlay an image with black corners or to bake the black corners into your art assets.
CALayer masking on the main window will cause the entire window to be rendered offscreen, which isn't going to be usable for even the most basic app on a real device.
I'd recommend either baking the corners into your art assets (for your NavigationBar, Toolbar, TabBar backgrounds), or overriding drawRect on the NavigationBar and Toolbar and adding a clip. Most apps I've worked on end up demanding a custom NavigationBar and Toolbar anyway, so there's not much reason not to do this.
If a truly abstract solution was really necessary (i.e. "I need 4 round corners absolutely everywhere, and I don't have custom art assets"), I think the easiest way would be to create four "round corner" image views and add them to a subview of the application delegate's UIWindow. This would also be much faster than masking the layer, as it'd create four small GPU-accelerated blend areas rather than one giant offscreen view to upload every frame. The main drawback (and the reason why I suggest the art asset version instead) is that orientation and bounds changes have to be handled manually for added subviews of UIWindow.
Sounds almost exactly me. I leave important emails in my inbox that I'm working with (and one or two from my parents). I have a max of about 10 at any time. Zero unread.
I would love to see these states represented:
- Unseen (sent but I haven't opened my inbox or cleared the notification)
I think GmailZero is perfect for your workflow. You can set your goal as inbox 10 instead of inbox 0. I could also see an argument for inbox 25 or whatever fits on one screen. Or maybe inbox 7 as the number of things you can hold in short-term memory...
