At its annual Adobe Max conference, Adobe announced plans to bring a complete version of Photoshop to the iPad in 2019.
Photoshop CC for iPad will feature a revamped interface designed specifically for a touch experience, but it will bring the power and functionality people are accustomed to on the desktop.
This is the real, full photoshop - the same codebase as the regular Photoshop, but running on the iPad with a touch UI. The Verge's Dami Lee and artist colleagues at The Verge got to test this new version of Photoshop, and they are very clear to stress that the biggest news here isn't even having the "real" Photoshop on the iPad, but the plans Adobe has for the PSD file format.
But the biggest change of all is a total rethinking of the classic .psd file for the cloud, which will turn using Photoshop into something much more like Google Docs. Photoshop for the iPad is a big deal, but Cloud PSD is the change that will let Adobe bring Photoshop everywhere.
This does seem to be much more than a simple cash grab, and I'm very intrigued to see if Adobe finally taking the iPad serious as a computing platform will convince others to do so, too - most notably Apple.
GrafX2 is a bitmap paint program inspired by the Amiga programs ​Deluxe Paint and Brilliance. Specialized in 256-color drawing, it includes a very large number of tools and effects that make it particularly suitable for pixel art, game graphics, and generally any detailed graphics painted with a mouse.
The program is mostly developed on Haiku, Linux and Windows, but is also portable on many other platforms.
This program has been around since the early '90s, and runs, among other platforms, on Haiku today. Amazing.
There's something about the macOS operating system that kind of drives people wild. (Heck, even the original Mac OS has its strong partisans.) In the 17 years since Apple first launched the first iteration of the operating system based on its Darwin Unix variant, something fairly curious started to happen: People without Macs suddenly wanted the operating system, if not the hardware it ran on. This phenomenon is somewhat common today - I personally just set up a Hackintosh of my own recently - but I'd like to highlight a different kind of "Hackintosh", the kind that played dress-up with Windows. Today's Tedium talks about the phenomenon of Mac skinning, specifically on Windows. Hide your computer's true colors under the hood.
I used to do this back in the early 2000s (goodness, I've been here way too long!). It was a fun thing to do, since you could never make it quite good enough - there was always something to improve. Good times.
Today (May 15, 2018) is the 30 year anniversary of CHI'88 (May 15-19, 1988), where Jack Callahan, Ben Shneiderman, Mark Weiser and I (Don Hopkins) presented our paper "An Empirical Comparison of Pie vs. Linear Menus". We found pie menus to be about 15% faster and with a significantly lower error rate than linear menus!
This article will discuss the history of what's happened with pie menus over the last 30 years (and more), present both good and bad examples, including ideas half baked, experiments performed, problems discovered, solutions attempted, alternatives explored, progress made, software freed, products shipped, as well as setbacks and impediments to their widespread adoption.
Fantastic read with fantastic examples. Set some time aside for this one - you won't regret it.
Look at this screenshot of MacPaint from the mid-1980s. Now look at this screenshot of a current version of Microsoft Excel for Mac. Finally, consider just how different the two applications actually are. The former is a 30-year-old black and white first party application for painting while the latter is a current and unabashedly third party application for creating spreadsheets. Yet despite having been created in very different decades for very different purposes by very different companies, these two very different applications still seem a part of the same thread. Anyone with experience in one could easily find some familiarity in the other, and while the creators of the Macintosh set out to build a truly consistent experience, there is only one significant piece of UX that these two mostly disparate applications share - the menu bar.
The lack of a menu bar in (most) touch applications is really what sets them apart from regular, mouse-based applications. It makes it virtually impossible to add more complex functionality without resorting to first-run onboarding experiences (terrible) or undiscoverable gestures (terrible). While menus would work just fine on devices with larger screens such as tablets and touch laptops - I use touch menus on my Surface Pro 4 all the time and they work flawlessly - the real estate they take up is too precious on smartphones.
If touch really wants to become a first-class citizen among the mouse and keyboard, developers need to let go of their fear of menus. Especially for more complex, productivity-oriented touch applications on tablets and touch laptops, menus are a perfectly fine UI element. Without them, touch applications will never catch up to their mouse counterparts.
Ending the year a new release of the "desktop engine" Arcan and its reference desktop environment, Durden.
Arcan is a different take on how to glue the user-experience side of operating systems together. It has been in development for well over a decade, with the modest goals of providing a more secure, faster, safer and flexible alternative to both Xorg and terminal emulators, as well as encouraging research.
The latest release improves on areas such as crash resilience, wayland client support, VR devices, OpenBSD support and visual goodies. You can read through the full release post, with some of the more technical bits in the related articles about crash-resilient Wayland compositing and "AWK" for multimedia.
I wonder if these rugged aesthetics, now commonplace in cutting-edge websites, can work at scale - in mobile apps used by +1b people. Instagram's new UI paved the way: can this effort be replicated in other categories (e.g. gaming)? Is brutalism a fad or the future of app design? Would it make apps more usable, easy-to-use and delightful? To end with, would it generate more growth? Conversions experts sometimes suggest that more text equals more engagement - what if we push this idea to the extreme?
There's something unsettling about these brutalist redesigns by Pierre Buttin - but I don't outright hate them. There's something very functional about them.
Can you spot the differences with the messages above? The left side has a few more capital letters than the right side. Big O, little o. Who cares, right?
Well, if you write for an app or website, you should care. A little thing like capitalization can actually be a big deal. Capitalization affects readability, comprehension, and usability. It even impacts how people view your brand.
While there are some more objective arguments to be made, most arguments for and against either title case or sentence case mostly come down to whatever you're used to - what you grew up with. Title case looks entirely ridiculous and confusing to me, and makes dialog boxes, text, and other things much harder to read than when it's in sentence case.
The reason? We don't use title case in Dutch. Everything is sentence case. In English, it's mostly a case of preference, and either case type is fine as long as you're consistent.
Interestingly enough, Apple - generally considered the poster child for title case - actually localises its choice for case type. When you run Apple software in, say, Dutch - it doesn't use title case at all, opting for sentence case instead, because that's the norm in Dutch.
Title case also appears to be on its way out - generally, while pre-internet publications use title case, publications originating from the internet generally use sentence case. I wouldn't be surprised to see title case fall into disuse almost entirely over the coming decades in English - including at Apple. There's going to be an inflection point where title case will simply look incredibly out of place in English, as younger generations grow up on new publications that do not use it.
Title case is old - very old - probably because lowercase evolved out of uppercase, and over the centuries, we've been slowly pushing uppercase letters to perform very specific functions in text. Capitals have become an integral and core part of punctuation rules in every (?) language using on the Latin, Greek (?), and Cyrillic (?) scripts, and while there is some variation here and there - e.g. German holding on to capitalising every single noun, not just proper nouns - there's a remarkable consistency between them.
I'm fairly certain English' title case is the odd-one out, and as the internet continues to break down barriers between cultures and languages, title case will eventually disappear from English, too.
Volvo recently conducted a survey and asked consumers about their perceptions of self-driving cars. The question that stood out to me was whether a car company like Volvo or a technology company (Google, unnamed) was best positioned to bring safe self-driving cars to the market. Volvo was obviously fishing for a particular answer, and while they certainly have a vaunted reputation for technical innovation in the service of safety, I'm afraid I can't go along with the answer they're hoping for, partially because safety is only part of the story. In my opinion, no car company working alone is going to be able to produce a self-driving car with the kind of usability that consumers will expect. And for self-driving cars, usability is just as important as safety. In fact, they're inseparable.
In 1996 Don Gentner and Jakob Nielsen published a thought experiment, The Anti-Mac Interface. It's worth a read. By violating the design principles of the entrenched Mac desktop interface, G and N propose that more powerful interfaces could exceed the aging model and define the "Internet desktop."
It's been almost 20 years since the Anti-Mac design principles were proposed, and almost 30 since the original Apple Human Interface Guidelines were published. Did the Anti-Mac principles supersede those of the Mac? Here I reflect on the Mac design principles of 1986, the Anti-Mac design principles of 1996, and what I observe as apparent (and cheekily named) Post-Mac design principles of 2016... Er, 2015.Quite a read, but definitely worth it.
My love of typography originated in the 80's with the golden years of 8-bit home computing and their 8x8 pixel monospaced fonts on low-resolution displays.
It's quite easy to find bitmap copies of these fonts and also scalable traced TTF versions but there's very little discussion about the fonts themselves. Let's remedy that by firing up some emulators and investigating the glyphs.
I've been looking at a lot of these 8bit fonts because of recent emulation efforts. I'd like to throw Visi On's fonts into the fray, too.
This is a bit of a weird topic, but I think it might be interesting to figure out what, exactly, is going on here. Ever since its very first release Chrome has had a very small, barely noticeable visual bug in its user interface: its window widgets (or buttons) are not aligned properly. As you can see in the screenshot below, they are shifted slightly to the right compared to a window without the bug.
Now, this has never been too big of an annoyance to bother the developers with, so I never made a bug report out of it, and I still don't think it's important enough. Chrome has a custom titlebar compared to regular Windows windows (because of the tabs-on-top), so I figured that was the cause.
Since yesterday, I've been using Firefox 29, and I noticed that it has the exact same bug:
Now my interest is properly piqued. Upon closer inspection, you can see that Chrome and Firefox actually have different offsets. The below image also illustrates that in the normal situation, the right edge of the close widget lines up pixel-perfect with the content area (the red line); this is not the case for Chrome and Firefox, where the close widget and content are misaligned.
These are two different applications with two entirely different codebases, and yet, they have the same visual bug, albeit slightly different in presentation. For some reason, this fascinates me; is it a limitation in how Windows handles custom titlebars? Is it, perhaps, a feature, and is there a deeper reasoning behind it? Is it just sloppiness? Do we have any Windows developers here who could possibly shed a light on this?
Some will call this petty whining, and surely, it is. However, I'm not asking this because I'm bothered by it; I'm asking this because I'm genuinely curious where this bug comes from.
There's certainly some hope on the horizon with Apple and Google, though just how good these systems will be remains to be seen. One thing is clear, though: the current state of all in-car experiences is incredibly bad. For those manufacturers looking to go it alone, I don't expect much.
In-car software is absolutely horrifying and crazy complex. A good friend of mine regularly drives brand new and super-expensive cars (in the hundreds of thousands of euros category), and even in those cars, the user interfaces are just terrible. There's a lot of room for improvement and disruption here.
Submitted by 
