Adding to the users asking Serif to fix this. I have not seen the roadmap (just searched, oh wait, you can't see it... bad sign)
I think the complaints going unheard may be due to the fact that it is hard to describe what's going on. EVERYTIME someone comes here from a search, the explanation of what a canvas and artboard are has to be repeated. Often people trying to be helpful respond "Click clip to canvas" EVERYTIME SOMEONE ELSE has to repeat "That's only for documents without an artboard" It takes a second to sink in after the support people chime in that this is by design.
If this was not a problem, it would not be hard to describe.
This should really be changed.
I know I'm supposed to say "In Illustrator... " but the artboards ARE pages on canvas. As a user I don't need to know that they are actually references to pointers to memory locations or whatever programmers need to worry about.
It is exactly the same as file icons and folder icons and windows in an OS. Users "open" a folder icon and "look inside" the folder through a window, BECAUSE THEY HAVE NO REASON TO BELIEVE THERE IS ANYTHING BUT THE OBJECTS!
My workaround, for which I am supremely grumpy, is to place rectangles at the very top of the layer stack that I will finally use to create artboards like "make cropmarks" in the software I formerly used (wink). I know this will require troubleshooting, and I haven't fully understood the whole "slices" situation, but I'm sure this doesn't solve that.
Fix it! Yes, I'm that angry user. I don't know if I'll bother with 2.0 unless this is fixed. Should we have to wait until then?
I wondered what part of Affinity's Adobe killer apps would start to become bad, I think they could be more responsive when they were smaller. I'm not laying blame on them become Adobe, just thinking about what happens when they have a solid product that is "good enough" and basic things are not taken care of.
Communication! If it seems broken and there is no word or evidence to the contrary, it's broken. Sometimes I think it would make more sense to just tell us that we are edge cases rather than not responding.
I like Affinity software. I hope they win. I will complain about this until it's fixed or I'm told it won't be fixed.
“By design” (emphasis mine). And herein lies the issue with some of Serif's decisions: bad UX design and the absence of choice for the user in order to fix/work around them.
If your users are actively contesting features that work the way they do “by design”, rather than just because of bugs, something is seriously wrong with your product and your vision, regardless of how good your sales figures are or how happy some niches (or even the majority!) of your users feel about it, and especially considering that adding those choices wouldn't hurt them in the least either way. A badly designed product can be way more frustrating and less dependable than a well designed, albeit buggy one.
Yeah, I'm bumping this thread here a bit as well, sorry. But just like the “advanced selection” one (probably even more so), it must be kept alive, as other posters said before. You already have our money and us as users, so… deal with it and fix it.
Hi! I just wanted to chime in… Even if you don't change a thing on the way AD treats artboards and layers, this feature (being able to toggle “Clip to Canvas” in multiple-artboard documents) absolutely must become available at some point in the future. Even if things may look a bit messy in certain documents, because of artboard positioning, that should be our choice to make. This modal logic that determines that a document can be in either single- or multiple-artboard “mode” (and it's an invisible mode, at that, not like your well-thought-out personas), with different tools available depending on which “mode” you're in, adds unnecessary complexity and makes the app feel a bit broken. And I'm not using the word “broken” liberally here; having access to objects that extend past the artboard edges, even if temporarily, is of paramount importance; how else are you supposed to be able to easily select (and drag) objects that may have only a smidge inside the artboard?
But wait: it gets worse. I was playing around and reading the forums here, and I found out a few things about AD that left me utterly dismayed. I understand that you can still make objects visible, even with the “Clip to Canvas” option grayed-out, by dragging them outside of the artboard they're in in the Layers panel, but then they won't export because the corresponding slices will be empty… even though it doesn't seem like it visually; when looking at the working area, the artboard/slice will seem to have content, but only after exporting the files or by looking at the layers panel thumbnails will the user realise they are, in fact, empty. In my book, this is a big UX no-no. It feels as if AD is working against you, in a quite frankly illogical fashion. Yes, I know it makes sense from a database/file structure standpoint, but from a visual standpoint it's a mess. So… artboards are these transparent, diaphanous entities that allow objects to show through, but unless you manually specify on a panel which ones belong to them, they won't show up when exporting. Are we working with a modern and supposedly WYSIWYG vector app with full PDF and pre-press support, or with AutoCAD ca. 1992?
Also… is there any replacement for artboards in AD, as in a proper slice tool that actually slices things in half but still shows up on the Draw persona? Because it seems you can't really slice an object between two adjacent artboards, as it can only “exist” on/belong to either one of them. That turns “Slices” into a bit of a misnomer when applied to artboards…
I hadn't done any complex, multi-artboard documents in AD before, but now that I started trying that out I realised just how limited AD is and… to be honest, I feel a bit cheated. Ai's implementation, all with two different panels, may feel cumbersome (I mean, all of Ai *is* cumbersome, the whole thing), but AD's implementation seems dumbed-down and broken by design. Lumping artboards with objects doesn't really make much sense if you think about it, and having your objects jumping around in your Layers panel without direct user intervention in said panel (that isn't creating, deleting or locking objects) is a big, BIG UX no-no in my book as well.
If I'm working on a complex multi-layer document (like, say, a map or a diagram), already spent quite a bit of time grouping objects into different layers, and need to use artboards/slices for some reason, that will completely screw up my workflow… I can either fight against AD by duplicating all my layers, moving them to the new artboard, etc. etc., or just cave in, fire up Ai and get it done in ten seconds flat (basically the time it takes to press Shift+O, select an artboard size and place it where I want it) and, even accounting for its excruciatingly slow opening time, I will still get it done faster (and in a cleaner fashion, without having to expand the file size and complicate it further with all the duplicates) than in AD. I understand that you wanted to make artboards into “mini-AD documents” inside of a bigger AD document, but shouldn't users be given some kind of choice on how to use that feature?
I honestly don't know how you can fix this and make AD more flexible without having to completely rework certain technical and UX assumptions (which might also break other people's workflows and documents). But, IMHO, I think you've screwed up royally with the multiple artboard implementation, as it feels extremely counter-intuitive and, frankly, useless for a sizeable proportion of your current and/or potential userbase. Please add a different type of artboard-like “thing” that doesn't mingle with (and screw up) layers, if you will, because these artboards, as they stand now, are utterly broken. Freehand (and even – *GASP* – Ai) got it somewhat right, so there's no reason AD shouldn't as well. Even though I have strongly complained on occasion about the lack of certain features in AD (I still think the Option+drag duplication behaviour feels wrong, and I still miss the option to have an object snap to its nodes on the “ghost” of its original position when dragging) or AP, I never thought I would ever write this on such strong terms: I believe you've out-Adobe'ed Adobe on the unintuitiveness department on this one.
Come to think of it, you were probably thinking illustrators and web designers would appreciate your approach, because it is indeed orderly and saves on panels, but I think it is too much left-brainy for either group, and especially for print designers and students (that may need to do certain imposition jobs by hand and absolutely need proper slice support for those). It really forces you to respect an excessively rigid hierarchy on the layers panel that both adds unnecessary extra steps and may not even make much sense from a functional standpoint.
Philosophically speaking, this reminds me of when Apple decided to remove the ability to have windows spanning different screens because of the revamped Mission Control. The difference being that they more than made up for losing that ability, because that multi-desktop system now feels tighter and more intuitive than ever. I mean, should you even be able to have part of a window overlapping a full-screen app? And how could they reconcile multiple virtual desktops with multiple screens? They did the right thing, IMHO, because they had to contend with two levels of 2D complexity, one virtual and one physical, that conflicted with each other.
On the other hand, having that kind of behaviour (i.e. objects that can't show up/exist on two different pages and be exported on both of them at the same time) on a WYSIWYG vector drawing app, which presents us with a single, rigid virtual 2D plane made of multiple content layers, makes absolutely no sense whatsoever. And considering different sections of that plane as different layers makes even less sense; if anything, if you really wanted to have them on the Layers panel and simplify the UI, they should all co-exist in a single special “Artboards” layer. Now THAT would make more sense. Your approach, sadly, turns something that should feel like an emulation of a physical working canvas into a… I don't know, a “Microsoft Windows 3.1's File Manager”-like thing, with boxes inside of other boxes?
I'm really sorry for sounding so harsh, but… yep. I do feel cheated. I can't really use nor recommend AD as unreservedly as I thought I could. And I'm also sorry I hadn't noticed these limitations during the beta process, because I would've strongly made the case for a better implementation like the one I've just suggested.
Anyway, if you want, I can send you some old multiple-artboard projects I did both on Freehand and Ai that would be nigh on impossible to make on AD (without getting seriously frustrated with your app, at least), with some context on all the workflow (including printing, trimming and mounting). If you are serious about print, you absolutely must try to fix this in some way. Even if you make slices accessible and visible in the Draw persona to make up for it (and yes, a user may wish to be able to work while seeing its slices, especially for planning around, you know, actual physical seams on the printed matter, without having to resort to extra guidelines and other fluff), I still feel that the route you've taken needlessly complicates using AD for daily, multi-artboard work. It is so weird and cumbersome that I actually considered using white rectangles and slices as faux-artboards to work around ADs implementation, really, but… oh, wait; slices can only be exported into raster files, not PDFs, so… yeah, you definitely have to fix this.
I have just installed AFP 1.8.1 on 2012 macbook pro osx 10.14.6. Whenever I push the swap button the app closes with no error. This is the first version I have installed on Mac and I have not used either version extensively.
afp_crash.mov
macafp crash info.rtf