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.
Submitted by 
