scamper

Exciting times. With precious little in the way of recent updates, some users wondered if Affinity was dead—but no, we were promptly told that they were just focused on the next major version. And four months later, here it is!
A common expression amongst users has been 'hopefully in version 2', so here's my list of hoped for changes. I'm about to fire up my new V2 apps for the first time and see if all the hopeful waiting has been rewarded. I've divided my list into two main categories: 'UI frustrations' and 'Missing or broken features'.
 
UI frustrations
Window management (Separated Mode)
Ever since MultiFinder appeared on the Mac in 1987, we've been able to run multiple apps and see their document windows side by side. Over the years came other improvements like drag and drop between apps and documents. You lose some of those benefits when an app takes up the whole screen with a solid background. For this reason, many of us preferred a separated workspace (turning off Application Frame in Adobe apps), but after switching to Affinity, quickly discovered that Affinity's Separated Mode was pretty broken, with document windows and Studio panels seemingly having no knowledge of each other's existence.
After much criticism, Affinity finally responded in June 2020 with a help article titled 'Increase your efficiency with Affinity’s Separated Mode'. There was no admission of any issues though, and I parodied the unhelpful article in this forum comment.
Changes in V2
Affinity seems to have finally acknowledged the issues with Separated Mode. Their solution? Remove it altogether! The new 'Float View to Window' command kind of gives us the worst of both worlds… separate windows that still aren't aware of your Studio panels, and a big old solid-grey app window obscuring every other background app. It looks like Affinity might have just put this one in the too hard basket.
Panel management
Resizing Studio panels in V1 is somewhere between painful and impossible. To be fair, this was never a perfect experience with Adobe either, but Affinity takes the pain to a new level. Can't see most of your Paragraph panel? Hover your cursor very carefully over that one-pixel hairline between panels… Nope, there's the 'no entry' cursor telling you the panel can't be resized (for some unknown reason). Double-click to minimise a panel or two to make more space… only to find that it added several inches of completely empty space to a different panel instead. Try to resize that one. Nope, there's the 'no entry' cursor again. Start double-clicking ALL the panels until you can finally see the one you want. Utter frustration.
Changes in V2
After playing around with panels for just a few minutes, the results are mixed. Firstly, I can resize panels (without seeing the 'no entry' icon all the time)—great! Secondly, the hover-zone seems to have expanded from one pixel to around two—I'll take it! Beyond that, things are still quite unpredictable. For example, I currently have a massive Swatches panel full of mostly empty space, and a tiny Text Styles panel below it which is showing me only two lines. I can resize the Text Styles panel to my liking, but if I then minimise and reopen it, it's right back to the way it was—tiny and useless. Whatever algorithm is determining these panel sizes is clearly not fit for purpose.
On a positive note, on the Mac the Studio panels are now listed under the Window menu—exactly where they should have been all along!
Oh one other thing… I lost the Swatches panel in Designer. As in, it just totally vanished. 😳 I can hide it and unhide it again from the menu, but it does not reappear. Restarting the app doesn't bring it back either. This could be a bit of a problem!! (Edit: Found!)
Working with guides
Creating a simple guide the normal way, by dragging out from the ruler, works fine. Unfortunately though, Affinity apps lack the power and flexibility of other drawing apps like Illustrator, which let you select and manipulate guides like normal objects—positioning them numerically for example, or hitting delete to remove then. Illustrator even lets you convert normal vector objects into guides.
With Affinity apps, you have to drag a guide off the edge of a page to remove it. The issues with this approach are (1) you have to be zoomed out so that you can see the edge of the page, and (2) it's inconsistent with the behaviour of other objects, which can be safely dragged and positioned beyond the edge of the page. This creates confusion for users as discussed on threads like this one.
Instead, Affinity gives us the Guides Manager. It's a useful tool, but it would be less necessary if guides were more flexible in the first place.
Changes in V2
There appears to be no changes to the way guides work in V2.
Working with colour swatches
In my opinion, Affinity seriously dropped the ball in V1 with the way colour swatches are handled. Here are some of the features that are missing or broken:
There's no obvious place to put your custom colours. You have to find the 'Add Document Palette' command first, which then creates something called 'Unnamed'. Other actions may trigger the app to add a second palette named 'Document'. Once a swatch is created, you can't convert it to or from a global or spot colour. You can't select more than one swatch at a time. You can't drag and drop colour swatches between palettes or between different parts of the UI. There's no obvious way to add a Pantone swatch to an existing document palette. (You need to apply the colour to an object on the canvas, select the object, switch back to your document palette and click on one of the two 'Add…' buttons.) New global colours are given generic names (Global Colour 1, etc). Pantone colour names are not preserved when added as global colours (the most common requirement!) and need to be typed in manually. Global colours are not transferred between documents when copying and pasting objects. (You need to explicitly export a palette from the first document and then import it into the second document.) Global spot colours are not added to a Publisher document palette when placing a Designer file (unlike InDesign and Illustrator). There's no search field in the 'Add Global Color' panel or edit colour pop-up, making it almost impossible to select the one you want from a large list of swatches. (They aren't displayed as a list, even if you set the panel appearance to 'Show as List'.) There's no command to find and delete unused swatches from a document palette. There's no option to merge two global colours. When deleting a used swatch, you're not asked what to replace it with. (If you delete a global colour, all instances just get replaced with a non-global version.) Yes, colour swatch management in Affinity V1 is bad—really bad. In one forum comment I wrote, 'That's one thing Adobe got right, and something the Affinity devs would have done well to replicate, rather than trying to get clever and do their own thing. Gosh I hope version 2 starts to take this seriously.' Well let's check out V2 and see…
Changes in V2
(1) The 'Add Document Palette' command now displays a pop-up which asks, 'Please enter a name for the new palette.' It still defaults to 'Unnamed', but it's a small improvement over the previous behaviour.
(9) Both the 'Add Global Color' panel and the edit colour pop-up now feature a search field, making it much easier to select from a large list of swatches. (They also now respect the 'Show as List' setting.)
Aside from those two improvements, very little seems to have changed with colour swatches across the Affinity suite. That's a big disappointment, and seems to communicates that the Affinity team don't share the view of many users, that this really needed an overhaul.
Undo/Redo
In Affinity apps, the action of selecting or deselecting an object gets added to the undo/redo stack. This is counterintuitive, goes against years of established practice, and (if the user is not familiar with it) can lead to data loss. Only an action that alters the artwork in some way should be added to the undo/redo stack, as discussed here.
Changes in V2
Nothing has changed.
 
Missing or broken features
1-bit black and white artwork (line art)
Graphics applications have, since the beginning of time, supported true 1-bit black and white artwork, so many professional users were understandably shocked to discover that Affinity V1 apps offered no support at all for 1-bit files. The only workaround is to work with grayscale and manually compress your lightness levels. This is anything but reliable, as compression algorithms at export time will not recognise the difference between a faux B&W image and a grayscale one, downsampling line art to an unacceptably low resolution and adding unwanted antialiasing.
Changes in V2
Incredibly, there's still no support for 1-bit black and white artwork.
Turning off antialiasing
The ability to turn off antialiasing of exported graphics is an essential feature for any professional graphics application. Affinity V1 apps lacked this feature entirely in the beginning, but in response to a forum post in 2015, one of Affinity's developers added highly-customisable, per-object control of antialiasing. Then, in 2020, it got better, with a simple on or off option, which you can apply to multiple objects at once.
This is a huge improvement already, but some of us would still like to see a simple on/off checkbox at export for outputting something like a raster print versions of a logo. As I explained in the same discussion: 'it's about tailoring the artwork to different output media. That should be an export function, not something I have to hard-code into the design file.'
Changes in V2
Turning off antialiasing cannot be done globally at export—it must still be hard-coded into each object of the file.
Reliably exporting for print
Affinity Publisher's default PDF export settings for print-ready artwork ('PDF (press-ready)') turns black (K:100) to a CMYK mix (e.g. C:71, M:66, Y:66, K:76), which would be a disaster if not detected before your job goes to print (something which is difficult when there are no pre-press tools provided). There are other issues too, like line art being downsampled and antialiased (related to the previous two issues).
Changes in V2
This has not been fixed. The 'PDF (press-ready)' export preset still has an all-or nothing 'Embed profiles' option ticked by default, and still causes black artwork (like text) to get converted to a CMYK mix.
Previewing colour separations
Affinity has no alternative to Acrobat Pro. For print professionals, this means no way of previewing and checking colour separations before going to print. When combined with the issues mentioned above, the chances of poor quality artwork and printing are high.
Changes in V2
There are no new apps or built-in tools for checking colour separations.
 
Summary
V2 may have brought some cool new features, but it has only brought modest improvements to a few of the features which matter to me the most, while other issues have been overlooked completely. Having waited so many years for the first major update, I have to say, I'm pretty disappointed.
I'll still purchase all the apps, and I'll still recommend them to family and friends. They do a lot of great things, and you certainly can't beat the price.
Of course, this is not an exhaustive list of the issues I have with the Affinity apps—just a few that frustrate me the most. If I've left out some of your biggest issues, feel free to add them below with a note on whether V2 fixed them for you.

This.

completely agree on this as a macos user.
the seperated mode is a completely basic macos function, immanent to the possible workflow in macos - and as such, programms that are sold for macos, that are lacking this feature, are somehow incomplete regarding the os support.
so please make the seperated mode possible again. thank you

Nope, it was a useful feature of the app, and it is important for me, now this it is removed. Do all users should use it? No. But for me, as one of the users/customers it was one of the main features in every day work. So, yes I want it back.

Hi!
I have Photo and Designer v1, and a full set of v2. I"m a professional designer and I have been an Adobe user for about 18-20 years and still am. And in version 1 of your app there was an option to use it as  photoshop or illustrator without the background of the app. Adobe calls it "application frame", you call it "split mode". And in v2, you don't have that. You have "float view," but it doesn't make sense. In "float view" the toolbar constantly wants to jump to the file window, and the file window can be positioned above the "studio" panels, and that's very strange. I really think Designer v1 and its FX add-on aka Photo v1 is the best illustrator/photoshop alternative on the market. But not v2. Give me back the "separated mode" and fix the weird UI behavior.

Best wishes,
Your disappointed user.

Showing or hiding arbitrary groups of contiguous layers is much faster in Photoshop, solely because Adobe is using a custom control that lets users click+drag. Since Designer uses a traditional checkbox for the same function, users must click each individual layer they wish to hide (or select the layers first and click one checkbox to affect all selected). I usually rail at Adobe for using non-standard UI affordances, but in this case it’s hugely beneficial to be able to show and hide vast numbers of layers at once. This is definitely one of those things that you do more often than you think!
Attached image illustrates this better than I’ve described it. Please let me know if I’ve overlooked something. Otherwise, it would be nice if Serif implemented a similar mechanism for Designer.

I appreciate workarounds—I mean, that’s a daily part of the job, right?
What I’m really asking for though is for an option to apply noise as a factor of an effect, and not as part of an object’s color (or layer). Final illustrations below, then I promise to shut up.  
Example 1 shows that AD currently associates noise with the color attribute. This has certain limitations, as we’ve seen above. Example 2 shows the Photoshop comparison, where each effect can have its own noise amount. This is an attribute of the effect itself, not the color, or the shape. Example 3 then shows what I’d like to see, where noise is just another modifier on a given effect (Outer Glow in this case). Anyway, I see the current behavior as a quirk, that’s all. It would be lovely to see some improved flexibility in this area, but the show must go on.

I’ve noticed that there seem to be two different types of noise that AD applies, based on where you apply it. Noise applied to a shape’s fill appears to be resolution-independent (what I’d expect), which means it’s not based on the resolution of the image/viewport. However noise applied to an effect* appears far coarser, as if it’s being applied as a bitmap. The attached image, if it’s not too compressed, should illustrate the difference in appearance. Shouldn’t noise always be the same?
*Why is noise generally so hidden in AD? In the layer effects window it should have its own dedicated slider rather than being tucked under color.

I appreciate workarounds—I mean, that’s a daily part of the job, right?
What I’m really asking for though is for an option to apply noise as a factor of an effect, and not as part of an object’s color (or layer). Final illustrations below, then I promise to shut up.  
Example 1 shows that AD currently associates noise with the color attribute. This has certain limitations, as we’ve seen above. Example 2 shows the Photoshop comparison, where each effect can have its own noise amount. This is an attribute of the effect itself, not the color, or the shape. Example 3 then shows what I’d like to see, where noise is just another modifier on a given effect (Outer Glow in this case). Anyway, I see the current behavior as a quirk, that’s all. It would be lovely to see some improved flexibility in this area, but the show must go on.

I second the need for a keyboard shortcut to delete. Having to tap the trash can icon when I want to delete something is cumbersome and breaks my flow. It’s also a different behavior from the desktop app so as a Pro user who uses both I have to pause each time I want to delete some element in Designer on my iPad and will always hit the Delete key several times before I realize that I have to tap the icon. If you’re worried about people accidentally pressing delete as you would on desktop and.. deleting something, maybe you could add a switch in the preferences to enable this function for those of us who just want to get our work done
 

What I found most interesting about that topic (& the reason for the 'stir the pot' emoji) is there were multiple suggestions regarding how guide locks should be implemented ... & objections to each of them.
There were at least four suggestions for where the toggle should be placed, including in the Snapping Manager, on one of the app menus, on the toolbar, & in the Guides Manager. Several people favored a modifier key to unlock & enable moving the guides instead of or in addition to a toggle. Two users, including @paolo.limoncelli of Daub Brushes fame, favored Xara style guides layers.
@Patrick Connor really stirred the pot by mentioning that "long term," it might be possible to lock/unlock guides individually, suggesting that there are still more changes to come in the Guides implementation/functionality.
Something else I noticed from the various comments in both topics: some people use Guides more or less like a second or supplemental form of Grids, usually set once & rarely changed; while others use them more dynamically, adding/removing & moving them on-the-fly as needed. This is probably at least part of the reason there are so many different ideas about how guide locks should be implemented, or if this feature really is needed.
Just some more stuff to think about....

Based on the lastest Publisher beta, as far as I can tell no method to lock guides is available.
Here is why the current guides and columns implementation is a rather misguided one (pun intended
First, let's list @R C-R's objections to a guide lock feature:
perform many different tasks with the move tool based on canvas position; accidents are more likely &  this workflow requires more care, but works faster than otherwise would be possible; avoids the need to open a menu or click a button to lock guides (extra work), and vice versa no need to deactivate a guide lock (less work) and prevents me from being unable to work with existing guides. adds interface/workflow clutter, making goofs more likely what would prevent the user from accidentally push a lock guides button? A lock guides button is just as prone to accidental mistakes as, for example, the layer lock button. the current visual cues and hints are more than enough to warn the user and prevent the user from accidentally moving guides with the move tool adding this lock guides feature may result in endless amounts of 'goof proofing' (because preventing any sort of accidental change would require this: where does one stop?) the user is just as prone to accidentally move a canvas guide, as they are mistakenly clicking a lock guides button Next, let's assume we work with a simple magazine-type layout template, consisting of multiple grids (and I would like to emphasize that this is a very simple grid-based layout). As anyone even remotely familiar with layout design is aware of, good layout grid controls are a basic ingredient):

Now, before I discuss @R C-R points, this already highlights one of the issues we encounter with Publisher's "innovative" new columns approach: only ONE (1) column grid may be defined per master page (or per page). In page layout design more often than not multiple page grids and sub-grids are defined on any one page and/or page template.
I solved it here by first creating a 12-column grid, then placing guides, and then create a four-column grid. That's as far as I can go: if I want to create another 8-column grid at the top third of the page, or a sub-grid to define image positioning on the right of the text columns, and another one on the left, I encounter several challenges in Affinity Publisher:
The space/layer in which guides live is a "special" guide layer. Only one (1) set of guides can be defined on this "guide plane". It is impossible to create multiple guide sets. It's either all guides, or none that are visible. [2] would be somewhat workable if guide presets could be saved. They cannot, so it is not possible to quickly switch between guide sets. Guides do not really behave like other objects. For example, it is not possible to select multiple guides, and move these simultaneously. These issues are prevented in other design applications (such as InDesign) by basically treating guides as more or less regular objects. Guides can be placed in any layer. Multiple guide sets can easily be managed with multiple layers.
So what about that snazzy novel Column Guides approach in Publisher? As far as I can tell, it is a work-around to provide a solution for Affinity's limitation that only one set of guides can be defined on the "guide plane". At first glance, it seems like a pretty attractive solution: it is non-destructive, and separating the guides plane from this new grid plane solves the immediate "only one set of guides" limit. And those visually attractive solid columns provide for some nice eye candy in Affinity promotional videos!
But examining this from a workflow point of view, it only exacerbates the entire page layout grid and guides workflow: 
still only one guide set possible at any time per page or master page still only one page grid possible at any time per page or page master to work with multiple page grids, the user must create additional master pages, a less than desirable and convoluted workflow taking much more time a quick temporary grid just can't be done without destroying either the guides or overriding the master page's column settings. it is not possible to create guide systems based on selections. In a sense, Affinity Publisher new Column Guides, being separated from the guides, are really sort-of attempting to find a solution for a problem that never existed, if multiple guide layer/sets would be possible on the same page or master page.
To say that 1 guide set and 1 column/row page grid are enough in page layout design is... Well, it is madness, and displays a complete lack of understanding how layout (semi)professionals work, in my opinion.
The sensible solution would be to either introduce groups in the layer guide manager, and allow these to be individually activated and deactivated on demand, or just drop the current approach, and implement guides as objects which can be used in layers.
 
Anyway, let's return to the topic at hand: the option to lock guides and @R C-R's list of objections to having such an option.
Even the above 12-column grid is a simple and commonly used one. Publications may go up to double that, btw, and introduce many subgrids in InDesign for various things.
Users tend to move things by grabbing the center of the object. In particular when a cross is displayed (check the image objects) a user's eyes will be focused on the center, and they will start dragging from that point. Because two guides are positioned near the center of these images, it becomes exponentially more common for a user to accidentally drag one of the guides, instead of an image object. This immediately is a counter-argument to points [2], [6], and [8]: users will not carefully position their mouse cursors and wait for a visual cursor hint to pop up and then move the object. Users do not wish to or will not second-guess this type of drag and move action: it is kinetic memory at work here, and a user expects the object to move when they move the mouse cursor on top of an object. The focus of the action is the image boxes, not the guides. 
(within this context it is interesting to note that this is related to the selective attention test behaviour and the famous invisible gorilla experiment: humans focus on what is important to them, not on secondary fluff - in this case, guides are not important to think about or focus on).
The result is predictable: users WILL grab those guides by accident OFTEN. They can't help themselves, and they are not to blame: that is just how users visual systems and cognition works. This is why a lock feature is absolutely essential, and why any other design application in the market includes one.
It also means FAR more work to correct mistakes, and this is a counter-argument to point [2]'s assertion that without a guide lock option a user would work faster than otherwise possible. It depends on the situation, of course, but in complex page layouts with many guides this is obviously not true. Even handling a simple page layout with a couple of guides which happen to be close to the center of objects create many more accidental mistakes than expected.
Points [4], [5], [8]: As long as the guide lock option is hidden in a meaningful place in the GUI, accidentally turning it on (or off) becomes nigh-on impossible. For example:

To lock layers would take a number of conscious steps: Open the menu. Navigate to the Guides menu option. Click. Navigate to the Lock Layers option. Click. Close the window. Too many steps to "goof up" accidentally. Or at least, not very likely. That said, an unsuspecting novice user might find it troublesome to discover guides in a document sent to them cannot be re-positioned. My opinion is that this negative user scenario does not outweigh the positives of a guide lock option for the far majority of users and user scenarios, as proven by other design applications.
As for [4]: We must distinguish between GUI clutter and workflow clutter/inefficiencies. Yes, it does add one more checkbox. Does it clutter the GUI in the above example? I don't think so. It feels like a logical addition. As for the workflow with guides, it would be improved, as already stated.
Besides, novice and low-level users wouldn't even notice this option, because they would probably hardly open this dialog (excepting the user scenario mentioned earlier). Which means nothing essential is lost in either GUI or workflow, and important control over workflow is gained.
[1] [perform many different tasks with the move tool based on canvas position]: nothing would change in this regard if a guide lock feature is implemented. Indeed, it would simplify working with this tool and having many layout elements with a large number of guides. Currently, the only option to prevent accidental guide repositioning in a document with many guides is to switch to the node tool. But the node tool hides text boxes, and cannot be used to move vector objects (other than the "live" vector objects, which is an inconsistency if you think about it).
In short, without a guide lock option the user may actually be forced to use the node tool.
[7] [adding this lock feature may result in endless goof proofing - where does one stop?] No-one in this discussion asked for more than a simple guide locking feature. And I think I have disproved your assertion that a guide lock option would be "goof proofing": instead, it is an expected and common useful addition to assist in complex layout design control. A layer lock option achieves the opposite: it improves the usability of Affinity as layout design software.
Conclusion: a simple guide lock option solves many workflow issues related to Affinity's three apps when dealing with more complex and controlled layouts. Even in relatively simple layout design guides may be accidentally selected instead of the content, depending on the visual status of the document. It also wouldn't increase either GUI clutter or cause an inefficient or confused workflow - rather the opposite.
Aside from this, in my opinion the Affinity Publisher devs are attempting to find a solution for a core issue in all their applications: the single-layered guide plane. The current columns solution works okay for simple layouting, but is merely a work-around for not having to deal with that core issue. My opinion, of course. I am sure many Publisher users will laud this as the most innovative thing ever to be seen in a publishing application. In the meantime InDesign runs circles around Publisher for complex page layout design controls.
[apologies for this rather long piece :-) ]

For me, it isn't just about avoiding clutter. It is also about avoiding the need to go into a menu or click a button to avoid doing something I can quite easily avoid doing simply by paying attention to the visual cues the app offers, & likewise about letting me do whatever I want to do when I want to do it without having to bother with checking anything that might otherwise prevent me from doing it.
In Affinity, the original issue users complained about was that one could not do anything under a guide on the canvas because it was above all other objects. That issue could have been & indeed briefly was resolved in the beta using the 'old school' method of adding a lock guides option, but that does have the drawbacks mentioned above; so at least to me that makes the current beta behavior a better, more elegant & less complicated resolution of that particular issue.

Don’t get me wrong … I perfectly understand your intention, and I would wholeheartedly subscribe to the principles of usability and avoidance of clutter you are advocating so vigorously. I just don’t see why a simple menu option, as it was available in Pagemaker in the 1980s – and is, to repeat myself, available in every other professional graphic design app I am aware of –, should “clutter” the interface of the Affinity apps. I really don’t care for a button on the main toolbar. The developers could hide the guide lock option in a submenu, should it prove too difficult to create a layer-based guide system at the moment, but nonetheless, it would be a huge relief and a great improvement for my workflow, if I could just lock my guides. 
I think you have to acknowledge that the option of locking guides is present in these other apps for a purpose, and it is present there for over thirty years now. It is needed, it is simple and effective. I don’t see how the current approach could provide the same qualities. 

No offense taken, but while I believe this to be a legitimate request, I still think it is just one of the many such requests for 'goof-proofing' the app that would unnecessarily complicate the UI, making various kinds of 'goofs' more rather than less likely.
One of the things I like most about the Affinity apps is the 'less is more' nature of the UI. In particular, I really like that I can do so many different things with the Move Tool just by changing where on the canvas I use it, without having to go to the toolbar or worry about which buttons or modes are enabled. I have worked with apps that instead require the use of different tools for different functions -- even one that requires the use of separate tools to perform selections, translations, rotations, & so on, if you can believe that -- & they all feel archaic in comparison to the Affinity Move Tool.
I get that this does make some accidents more likely, & requires more care to avoid them, but I think it is a good compromise, one that lets me do much more faster than would otherwise be possible.
As always, YMMV.

No offence, R C-R, but I give up at this point. I put my trust in the developers that they will understand that having a guide lock option is a legitimate request. 

when rulers arrive, might the user be able to set where the zero point is..in the case where you need the origin to be other than the top left corner of the document or art board?
 
thank you 

I think a lot of the help info was copied over from Desktop version. There are a few other 'anomalies' that you will come across. Rulers will hopefully make it to the next release, along with import palettes etc.

Love this app on the iPad! Great job! 

I have spent some time with this app today...all day :) and there is something I would love to see added to the app. Rulers. Rulers are always a crucial part of my workflow and I know it is for other designers out there. I really like this app and still digging into the ins and out of it.
Thanks for finally creating a very powerful vector app for the iPad thanks works amazingly. 

From the current Mac Affinity Designer Customer Beta (1.6 - Beta 8) page:
Added ability to rotate the selected nodes in the Node Tool - via the Transform panel It is not yet quite working as intended, but @MattP says they should be able to sort out the bugs, so it should not be too long before the 1.6 release versions for both Mac & Windows are available & include that feature, among many other improvements.

When I import swatches using the “Import Palette…” item, I should be able to select palettes saved from Photoshop (ACO – Adobe Photoshop Color Swatch File) or Illustrator (ASE – Adobe Swatch Exchange File).
 
Are there foreign palette formats that AD can import? Maybe that information should be in the Open dialog box… or somewhere. (The Help Center doesn’t seem to do anything. I can search for a topic like “palette,” but can’t expand the results, so maybe the AD entries are just stubs?)

If I draw or select a shape, its handles and bounding box are active as long as it's selected. Okay so far. But when I elect to add a Layer Effect, the handles and bounding box should be temporarily hidden, as they can obscure the very effects I'm carefully applying.
 
I realize that, unlike Photoshop, AD allows me to edit/deselect a shape even while the Layer Effects window is in the foreground. It's not really a modal window! So what's the solution? Well, a compromise might be to hide the handles and bounding box, when the Layer Effects window is present, unless my cursor explicitly moves over the active shape -- making those things more sensitive to my actual intent, in other words. Otherwise assume that I need those to be hidden until I've dismissed the Layer Effects window.

If I draw or select a shape, its handles and bounding box are active as long as it's selected. Okay so far. But when I elect to add a Layer Effect, the handles and bounding box should be temporarily hidden, as they can obscure the very effects I'm carefully applying.
 
I realize that, unlike Photoshop, AD allows me to edit/deselect a shape even while the Layer Effects window is in the foreground. It's not really a modal window! So what's the solution? Well, a compromise might be to hide the handles and bounding box, when the Layer Effects window is present, unless my cursor explicitly moves over the active shape -- making those things more sensitive to my actual intent, in other words. Otherwise assume that I need those to be hidden until I've dismissed the Layer Effects window.

Is there a way to transform only selected nodes within a shape? I can select nodes, but I can't figure out how to scale, rotate, or skew them, though I can apply those functions to the entire shape.
 
In Photoshop (for example) I can select any number of nodes within a given shape, then hit Command-T to enter Free Transformation mode. From then on, any transforms will apply only to the nodes I had selected.

I've attached an example. I just want to know if this is (yet) possible in AD, as it's something I actually find myself doing quite regularly. (Apologies if I've missed something!)

When I'm in a numeric text field, holding down the Shift key as I tap the arrow keys should increase/decrease the value 10x.

(At the moment this key combination acts to select the text before/after the insertion point, which, while standard behavior for text fields, is not the expected behavior for numeric input fields.)