The long-awaited Photoshop for iPad is available to download today, and to keep the momentum going, Adobe is announcing that it’s also developing Illustrator for the iPad, to be released by the end of 2020. The vector graphics program has been optimized for the tablet and features core Illustrator tools like paths and typography, in addition to some new tools developed specifically for the touch experience.
Similar to how Photoshop on the iPad has its Cloud PSD files, Illustrator on the iPad will have Cloud .AI files that can be synced across Creative Cloud and opened from either the desktop or iPad. Cloud documents can be downloaded to the device and made available offline, so you can continue to work on your files in situations where you don’t have Wi-Fi, like on airplanes.
Illustrator for iPad has been in the works for a while, according to Adobe senior product marketing manager Wayne Hoang. “We’ve been thinking about bringing vector capabilities to the iPad for a long time. [Some of the features have] just been waiting for the hardware to catch up so we can actually implement them,” he says. The app is a combined effort between the core Illustrator team and designers who have worked on Adobe’s other new iPad apps, like the painting and illustration app Fresco.
Unlike most of Adobe’s previous iPad apps — like Photoshop Sketch and Illustrator Draw, which were considered “lite” mobile apps — Illustrator for iPad represents the next phase of the nearly 30-year-old software. “Some of this you’ll find similar to the way we talked about Photoshop on the iPad — it’s full fidelity,” senior director of design Eric Snowden says. But like Photoshop on the iPad, designers shouldn’t expect a full mirror of the desktop app on the iPad version.
Adobe has been busy ushering in a new era of mobile-focused apps this year, releasing Photoshop for iPad, Fresco, and Project Aero all just in the past few months. With an increased focus on bringing more of its apps to tablets, Adobe is selling the idea that its products can be versatile enough to evolve with the devices its customers use. Its hope is that Illustrator for iPad will be a companion to people who use the new Photoshop and Fresco apps. “If someone has all three of these products, how are they greater than the sum of their parts? How do we make those workflows really seamless?” Snowden says.
There’s no pricing information yet, but if pricing for Fresco and Photoshop for iPad are any indication, Illustrator for iPad could be included as part of a Creative Cloud subscription, and offered at a standalone monthly price for non-Creative Cloud subscribers.
I was shown a beta version of the app in a preview demo, and though it won’t be available for another year, I was impressed with how complete it felt. The UI is similar to the other mobile-focused apps Adobe released this year, like Fresco and Photoshop, which was an intentional choice. The app is designed in a way so users don’t necessarily have to be Illustrator pros to use it, with contextual menus that automatically pop up depending on which tool you’re using.
“When you think about the desktop, you have all these panels, there’s like 23 different panels,” Hoang says. On the iPad, “everything is just simplified.” There are tools unique to a tablet device, like photo masks, or that haven’t yet arrived on the desktop version, like Symmetry, which lets you live draw with a mirror effect. Here are some of the best and biggest features that’ll be available on Illustrator for iPad:
The pen tool, used for creating vectors, is Illustrator’s most powerful tool, but also one of the trickiest to master on the desktop program. There’s a challenging learning curve because it requires holding down certain keys for fine-tuning points and lines, like when you want to move Bézier handles. On the iPad version, the pen tool has been rethought in the context of a touch device so you can work without a keyboard. There’s an on-screen button called the touch modifier, which acts as a keyboard shortcut. It’s contextually related to whichever tool you’re using at the moment, so you can hold it down to switch to the sub-tool options.
Like a cursor, tapping different points will produce straight lines; holding and dragging will produce the curves. Anchor points will be added or deleted automatically when you click on a part of the path, switching between the Direct Selection and Selection tools seamlessly, and pixels can be adjusted manually down to the exact number in a side panel. “We wanted to make sure that while it felt quick and fast and easy to use, that we didn’t sacrifice precision,” Snowden says.
Point gradient, or freeform gradient as it’s called on the desktop, is a relatively new feature to Illustrator that was first introduced last year. The tool allows you to apply gradients on an unlimited number of color points. “Especially with the Apple Pencil and touch, this tool just makes a ton of sense,” Snowden says.
One of the standout features of the iPad app, construction guides take a sketch from an imported photo and use Adobe’s AI Sensei platform to find the underlying shapes and automatically trace the lines. It’s similar to the Image Trace feature in the desktop version, but much more intuitive. “It’s not creating a million different points, it’s creating exactly the number of points you need,” Snowden says. “The idea is we take that drawing and we get you 90 percent of the way there. Then as the creative, you can go in and finesse that and tweak all those different things.”
Pattern and Radial repeat
Illustrator is great for making patterns and letting artists quickly create seamless designs. There are dedicated tools for creating both Pattern and Radial repetitions, with a “spacing properties” panel on the side that lets you customize the effect with different overrides for changing the size and shape of things.
Symmetry allows for creating mirrored shapes that are connected to each other, and users can also make live edits that are reflected on the other side. Symmetry doesn’t yet exist on the desktop app — there are workarounds to do this on the desktop through multistep processes or third-party plug-ins, but it’s one of the most requested features in Illustrator.
It’ll be coming to desktop later, though, which shows how development for the iPad has informed decisions for Illustrator on the desktop as well. “We’re thinking hard about, ‘how can what we learn on the iPad be transferred back to the desktop, and how can the innovations on the desktop come back and forth?’,” Snowden says.
Clipping masks make use of the iPad’s camera feature, letting users fill vectors with imported photos from the camera roll or ones taken on the spot. “A lot of the stuff we’re trying to do is about taking things that take several steps right now, and just minimize them as much as possible,” Snowden says. You’ll notice there’s also a “Construction guides” toggle that pops up, which when switched on, will auto trace whatever’s in the photo.
The app makes use of Adobe’s fonts library, which has over 17,000 fonts. That’s a lot of fonts to be searching through on an iPad, though, so users can filter by classifications like serifs, or search fonts by natural descriptors like the kind of mood a font conveys.
Introduced as DeepFont in 2016 at the Adobe Max Sneaks keynote where experimental features are previewed, Unoutline Text is another impressive feature that uses Sensei to identify fonts. Designers will often run into issues where they’re given an image with type that’s been outlined, and they need to find which font it is in order to edit the text. Unoutline Text can analyze and find the font (as long as it’s available in Adobe’s font library), and let designers edit the text, kind of like Shazam for type.
A brand refresh is no small task. Especially when you’re a company that’s rooted in design—there’s an added pressure to get it right. For us to get it right, collaboration was a major theme. In fact, collaboration was the colorful thread that tied the whole process together. From the pushing-the-envelope brainstorms that involved our cross-functional teams, to the methodology behind the new illustrations, to the way we used Figma itself to bring our ideas to life.
Here’s how we landed on Figma’s new look and feel.
I joined Figma about a year ago with the goal to evolve the brand. Of course, I was familiar with Figma, but as I started dissecting the brand language under this lens, I realized there was a lot of great work that already existed. We didn’t need to start from scratch, we just needed to give Figma a longer runway than it currently had. The foundational brand language already had strong pillars conceptually and value-wise, but when they were established, Figma was a new and smaller company. We needed an expansive brand language that would match how much the company has grown. For example, we have a blog now. If a designer is working on a visual for the blog, what rules should the image follow? We took the limited brand guide that existed and added new pages and chapters.
For that reason, what you see in the refresh won’t feel like it’s out of left field. It’ll look and feel like it’s still orbiting the same sun because we took inspiration from what already existed and gave it new wings. We’re taking those original ideas and hitting different angles and points and dialing up certain things. Like the shapes, for example. They’ve always been a part of Figma’s brand, but with the refresh, we found new places they could live and new ways they could be used that still made sense.
Before we designed anything, we started with a lot of research to nail down our strategy. In this process, it helped to think of Figma the brand as a living entity to better bring it to life in our minds. If Figma were a person, how does it walk and talk, and breathe and live? It might wear different clothes every day, but it still has a distinct style. Over the course of weeks, we put together a list of four guidepost personality words, but we included a few detail descriptors to clarify what we mean when we say that Figma is bold, for example.
Curious — Clever, playful, imaginative. This is your friend with the far-out ideas. They always want to be learning more and considering the things that might not be obvious.
Vibrant — Dynamic, confident, alive. Figma loves nerding out on certain topics and is proud of it.
Honest — Inclusive, empathetic, approachable. We’re never afraid to admit that we don’t know everything, but together we can figure it out.
Bold — Powerful, unexpected, non-conforming. We don’t live in the shoulds, we do what is right and true to us.
We needed a brand that could flex between being reserved and also playful. One that can go from consumers to enterprise, and we felt the words above got us there.
Some people might think we just made a bunch of fun new shapes, but there’s a clear methodology behind how they interact or collaborate with each other. We like to think about the shapes as people. People talking, working together, sometimes arguing, or just existing. The illustrations show that collaboration. Depending on how you position them, lots of harmonious compositions can be created. Of course, just like people, some shapes work well with others, while others do not.
There are different levels of illustration using the shapes depending on what the moment calls for. If it’s a place where someone is learning and needs absolute clarity, there are no abstract shapes. We include only the illustrations that are simple and straight-forward.
We want design to be more accessible to people, so a lot of our shapes are very simple. They might come together to form something complicated, but they distill down into basic shapes. In the illustrations, we sometimes show that process — how the shape is built.
We also wanted the illustrations to feel like they’re still in process. In design, there can be a tendency to share only when it’s complete and perfect. But we wanted to highlight the work that goes into making — it’s often messy, imperfect, changing all the time just like people are. We felt that this realness, this aliveness helped dial up Figma’s vibrancy. You’ll see in the illustrations that at least one element is being manipulated or edited. Nothing feels quite like it’s perfect or complete. We wanted to encourage people to highlight their mess and share how they create. Maybe that way, someone else can learn from your process.
In the search for a new brand typeface, a designer on our team came across one called Whyte from Swiss foundry Dinamo. At first glance, Whyte looks pretty normal, and then you look closer and you start to notice some oddities. Whyte actually comes in two different versions—standard and inktrap. We fell in love with the inktrap version because it references ink traps in design history. Historically, when people were using metal plates to manually print, ink traps were cut in to create a place for the ink to pool. At smaller sizes, it’s difficult to see, but when you blow the letters up, you can clearly see the notches. We loved it because that characteristic adds an illustrative element to the type itself and we actually wanted to highlight this part of the type’s design that is usually invisible. Whyte spoke to what we wanted to achieve — a seamless flex between nonconforming and reserved.
We worked exclusively in Figma for the refresh, which was a stretch to our creative muscles since we grew up doing this type of work in Photoshop and Illustrator. We had to come up with new ways to do things. But because we were already thinking creatively, it led us to some celebratory moments where we took an idea even further because of something Figma allowed us to do. Collaboration was a huge part of that. This wasn’t a project where we could or should divide and conquer. We needed to work together, and often, that meant simultaneously. That’s something we could only do in Figma. Whether it was through the process itself, or the illustrations we were creating, we wanted to find ways to demonstrate Figma’s power. For that reason, we hope that the refresh is a testament to what Figma can do.
See the refresh in action. Check out the all-new homepage, explore the typeface and updated color palette throughout the entire site, and see the redesigned social media graphics for Facebook, Twitter, and Instagram.
I’m a designer, creative director, and writer, with a BFA in graphic design from RISD. I’m originally from Florida, did a 10-year-stint in the northeast, and these days I’m on the West Coast. I live in San Francisco, don’t tweet about design, and try to love on people as much and best as I can.
December 6th, 2018 was a special date for WordPress: it marked the release of version 5.0 of the software that, to this day, powers more than one-third of the web. In the past, people working on the platform pointed out that there has never been any special meaning to version numbers used in WordPress releases; as such, WordPress 5.0 was simply the follower to WordPress 4.9. Yet, 5.0 brought possibly the biggest innovation since Custom Post Types were introduced in version 3.0 – that’s almost a decade, folks.
The Block Editor — codename “Gutenberg” — is now the new default writing tool in WordPress. Before its adoption in Core, our beloved CMS has relied on what we now call the Classic Editor. And, by the way, the Classic Editor isn’t really gone: you can bring it back by installing a plugin that restores the default editing experience you’ve known all these years.
So, why was the Classic Editor replaced? Essentially because it embodied an old concept of writing, a concept that was conceived when the only need of a text editor was to visually compose HTML code.
Not to create layouts. Not to embed dynamic content form heterogeneous sources. Not to offer a representation of what your post or page would look like when you pressed that “Publish” button, and go live with your piece of content.
In short, the Classic Editor delivered a very basic writing experience and, frankly, it always fell short at creating anything more than flowing text.
The Block Editor is based on the idea of content “blocks” in the sense that everything we can add to a page — a text paragraph, an image, an embed — is technically a block, that is, an atomic entity that’s defined by a certain series of properties. The combination of these properties determines the state of that particular block. Combine several blocks one after the other, and you’ll get the content of your page.
In this transition from unorganized text to rigorous content structure lies the biggest change introduced by the Block Editor.
Layouts pre-Block Editor
Before all of this bursted into existence, people who wanted to create a layout within WordPress had to choose between either of these options:
Create a custom template from scratch, getting their hands dirty with code – a noble intent, yet not so appealing to the masses.
Use a tool, better if a visual one, that helped them composing a page structure without having much code knowledge.
That’s how page builders were born: page builders are plugins that provide a visual way to compose a layout, ideally without touching a single line of code, and they were created out of necessity to fill a gap between visual mockups and the actual, finished website.
Page builders have always suffered from a bad reputation, for a variety of reasons:
They tend to be slow and bulky.
Some offer poor editing experiences.
They end up locking users into a framework or ecosystem that’s tough to replace.
The first point is as obvious as it is unavoidable: if you’re a page builder author (and, hopefully, aspire to sell copies of your product), you have to make it as appealing as possible; physiologically, builders started to slowly become big code soups with everything in them, at the detriment of performance.
The second point may be subjective, at least to to some extent. The third point, however, is a fact. Sure, one could be perfectly fine using the same tool for every project, perfecting knowledge of the instrument as time goes by, but the more you stick to it, the harder it gets to potentially stop using it one day.
The Block Editor aims to surpass this deadlock: from the user’s point of view, it aims at offering a better, richer writing experience, while, from the developer’s perspective, providing a unified, shared API from which to build upon.
A brief history of CSS layouts
If you’re old enough, you’ll probably know the story already. If not, it might be fun for you to hear what life was like for a front-end developer back in the day.
The first version of the CSS specification dates back to 1996, and it allowed an embedded stylesheet to add font styling, pick colors for elements, change the alignments and spacing of objects in the page. The problem was that, in those days, the concept of semantic HTML wasn’t exactly widespread. In other words, there was no clear separation between content and form. The markup we’d write and the appearance we want were completely intertwined in the same document.
This led to HTML elements to be used more for presentation purposes, than conveying meaning to their presence in the page. For example, on the layout side of things, this also led to to table elements being used to create layouts instead of actual tabular data. To achieve even more complex layouts, tables began being nested into other tables, making the page become a nightmare from the semantic point of view, its size grow and grow, and resulting very hard to maintain over time. If you’ve ever coded an HTML email, then you have a good idea of what life was like. And, really, this still sort of happens in websites today, even if it’s for smaller elements rather than complete page layouts.
Then the Web Standards movement came along with the goal to raise awareness among developers that we could be doing things differently and better; that style and content should be separated, that we need to use HTML elements for their meaning, and reinforcing the concept that a lighter page (in terms of code weight) is a fundamentally better option than an unmanageable ocean of nested tables.
We then began (over)using div elements, and juxtaposed them using the float property. The presentation focus was shifted from the markup to the stylesheet. Floats became the most reliable layout tool available for years, yet they can be a bit problematic to handle, since they have to be cleared in order for the page to return to its standard flow. Also, in this age, page markups were still too redundant, even though using divs instead of tables helped make our content more accessible.
The turnaround moment came in 2012, with the publication of the Flexbox specification. Flexbox allowed developers to solve a whole series of long standing little layout problems, complete with an elegant syntax that requires a lot less markup to be implemented. Suddenly (well, not that suddenly, we still have to care about browser support, right?), reliably centering things on both axises wasn’t an issue anymore. It was refreshing. Finally, tweaking a layout could be reduced to altering just one property in our stylesheet.
As important as Flexbox is to this day, it is not the end of the story.
It’s 2019! Let’s use CSS Grid.
If you’ve come this far reading this piece, we think it’s safe to assume that two things are for sure:
That we clearly aren’t in this industry to live peaceful, quiet professional lives.
The things we use are going to change.
In 2017, the CSS Grid Layout Module specification was officially published, but, as it always happens with CSS specs, its draft and interim implementations had already been around for some time.
CSS Grid is a bold leap into what CSS can and should do. What if we stopped micromanaging our pages styles, and started thinking more holistically? What if we had a system to reliably position elements on the screen that doesn’t depend at all on the markup being used, nor the order of elements, and that is, at the same time, programmatically applicable on smaller screens?
No, this isn’t just a thought. This is more of a dream; one of those good ones you don’t want to wake up from. Except that, in 2019, this has become a reality.
The main difference between Grid and Flexbox is more nuanced, of course, but basically comes down to Grid operating in two dimensions, while Flexbox is limited to one. Knowing what elements are going to be placed within the limits of a container, we can choose exactly where those elements are going to end up, entirely from directives written in the stylesheet.
Do we want to tweak the layout down the road? Fine, that modification won’t affect the markup.
The basic idea behind Grid is that elements are laid out in, well, a grid. By definition, a grid is composed by a certain amount of columns and rows, and the boundaries between columns and rows form a series of cells that can be filled with content.
The savings of this approach in terms of quantity of code being used to achieve the desired result are extraordinary: we just need to identify a container element, apply the display: grid rule to it, and then pick elements within that container and tell CSS what column/row they begin/end in.
The above example creates a 3×2 grid associated to the .my-container element; .element-1 is a 2×2 block that is inscribed in the grid, with its upper left vortex being positioned in the second column of the first row of the grid.
Sounds pretty neat, right?
The even neater thing about CSS Grid is the fact that you can create template areas, give those areas meaningful names (e.g. “header” or “main”), and then use those identifiers to programmatically position elements in those areas.
For those who have begun working in this business in the tables era, the code above is nothing short of science fiction.
More good news, anyway: support for CSS Grid is pretty great, today.
Using CSS Grid in WordPress
So, this is great, and knowing that we can do so many more things today than we could compared to a few years ago probably makes you want to give Grid a try, at last.
If you are working on a WordPress project, you’re back facing the two options mentioned above: do we start from scratch and manually coding a template, or is there something that can give us a little help? Luckily, there is a plugin that might interest you, one that we have created with a dual goal in mind:
Create a bridge between the Block Editor and CSS Grid.
Create a plugin that could perhaps make people move past the initial skepticism of adopting the Block Editor.
It’s called Grids, and it’s a free download on the WordPress plugins repository.
Grids only takes care of the layout structure. It puts a 12×6 grid at your disposal (called Section), over which you can drag and draw the elements (Areas) that are going to be contained in that Section.
The system allows you to manually specify dimensions, backgrounds, responsive behavior, all using visual controls in the Block Editor, but by design, it doesn’t provide any content block. Sure, one could see this approach as a weak point, but we think it’s actually Grids’ biggest strength because it enables the plugin to integrate with the myriad content blocks that other developers all around the world are creating. More so, in a way Grids helps bringing those blocks, and WordPress as a platform, in touch with CSS Grid itself.
Yet, even if the plugin doesn’t strictly produce content, it’s inevitable to put it in the same phrase with successful page builders, in fact comparing its functionality to that offered by those. If you care about concepts like separation of form and content, page weight, ease of maintenance, Grids offers a cleaner solution to the problem of creating visually appealing layouts in WordPress.
The generated markup is minimal. In its most basic form, a Section (that is, the element with the display: grid property) is only composed by its own element — of course, an internal wrapper (that couldn’t be avoided and that’s used for spacing purposes), and then one element per Area belonging to the Section. This is a huge step forward in terms of avoiding using unnecessary markup.
This choice also directly determines what happens in the eventuality that you disable Grids in your install.
If you don’t re-save your page again, what’s left of Grids on the front end is actually exclusively the content you put inside the content Areas. Not any extra markup elements, not any weird-looking shortcode.
On the back-end side of things, the Block Editor has a system in place that warns you if you’re editing a page that is supposed to use a particular block type, but that block type isn’t currently available: in that case, you could easily turn Grids back on temporarily, move your content in another place, and then get rid of the Section altogether.
CSS generated to create the grid is also dynamically added to the page, as an inline style in the portion of the document. We haven’t been exactly fans of styles written in the page directly, because ideally we’d like to delegate all of the styling to files that we could put under version control, yet this is a case where we found that approach to be very convenient.
Another viable option would have been to identify all the possible combinations of column/row starting/ending points, and programmatically map those with classes that could then be used to actually position elements within the grid. On a 12×6 grid, that would have lead to having a grand total of 36 class selectors, looking like this:
What if we decide to offer more control over how a grid is composed and, say, give users access to options that determine how many columns or rows form the grid structure?
We’d have to manually map the classes that we don’t yet have in the stylesheet (and release an update to the plugin just for that), or, again, generate them inline, and then add those classes to the grid elements.
While perfectly fine, this approach kind of goes against the idea of having a leaner, more scannable markup, so we’ve decided not to follow this route, and pay the price of having style dynamically put in the head of the document, knowing that it could be easily cached.
Because of the experimental nature of the plugin, the backend UI that’s being used to actually compose the grid is created with CSS Grid, and a set of CSS variables through which we control the properties of content Areas. Using variables has immensely sped up our work behind the grid creator prototype — had we chosen a different path there, things wouldn’t just be much longer in terms of development times, but also more complex and less clear to maintain down the road.
To further foster the adoption of CSS Grid, we need tools that automate the process of creating layouts with it.
While we have been seeing great examples of this technology out in the wild, it would be short-sighted to assume that every website that is published today has a team of front-end devs behind it, that can take care of the issue.
We need tools that produce good markup, that don’t hinder the maintenance of the website stylesheets, and, most importantly in the WordPress world, that can be easily integrated with the existing themes that people love to use.
We think Grids is a step forward in that direction, as it’s a tool that is built upon two standards — the Block Editor API, and CSS Grid — and, as such, suffers less risk of reinventing the proverbial wheel.
While we’ve been recording general interest in the plugin at the recent WordCamp Europe in Berlin – with Matt Mullenweg himself displaying a brief demo of the plugin during his keynote — we know that it still needs a lot of feedback that can only be obtained with real-life scenarios. So, if you want to take Grids for a spin, please use it, test it and, why not, suggest new features.