Jump to content
You must now use your email address to sign in [click for more info] ×

Allow objects to snap to their “ghost”, initial position during drag operations


Recommended Posts

2 minutes ago, Frozen Death Knight said:

Certainly wouldn't hurt to have. :P

Certainly not.

d.

Affinity Designer 1 & 2   |   Affinity Photo 1 & 2   |   Affinity Publisher 1 & 2
Affinity Designer 2 for iPad   |   Affinity Photo 2 for iPad   |   Affinity Publisher 2 for iPad

Windows 11 64-bit - Core i7 - 16GB - Intel HD Graphics 4600 & NVIDIA GeForce GTX 960M
iPad pro 9.7" + Apple Pencil

Link to comment
Share on other sites

2 minutes ago, walt.farrell said:

Or, just click in the X box, which highlights the current content, and replace it by typing +=w*.5

Oh my, I am not good at shorthand :$ Thanks for the additional way on how to get this done.

d.

Affinity Designer 1 & 2   |   Affinity Photo 1 & 2   |   Affinity Publisher 1 & 2
Affinity Designer 2 for iPad   |   Affinity Photo 2 for iPad   |   Affinity Publisher 2 for iPad

Windows 11 64-bit - Core i7 - 16GB - Intel HD Graphics 4600 & NVIDIA GeForce GTX 960M
iPad pro 9.7" + Apple Pencil

Link to comment
Share on other sites

  • Staff

or use "+=w/2".  Even shorter.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

  • Staff

Thing is - adding "ghost" objects to everything that might snap is not a small task.  We're talking about quite a few tools.  Also - while it is trivial (ish) for the Move tool since we would only preserve the original bounding box for snapping purposes, it is less trivial for the Node tool, Point Transform tool or others.

 

I'll have a think about it as an option for snapping (since it is only really relevant as an extension for snapping purposes).  Not going to say when it might get done though.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

8 minutes ago, Ben said:

or use "+=w/2".  Even shorter.

Not only shorter, but more accurate in some cases.

15 hours ago, dominik said:

This even works for fractions where there is no snapping point at all, like fourths or thirds :)

For thirds, the best you could do with a multiplier is something like "+=w*.333333", so "+=w/3" is the better option.

Alfred spacer.png
Affinity Designer/Photo/Publisher 2 for Windows • Windows 10 Home/Pro
Affinity Designer/Photo/Publisher 2 for iPad • iPadOS 17.4.1 (iPad 7th gen)

Link to comment
Share on other sites

10 minutes ago, Alfred said:

For thirds, the best you could do with a multiplier is something like "+=w*.333333", so "+=w/3" is the better option.

This, indeed, is a good example for this way to write it down.

I noticed the section in the help about expressions. I'll take a look at it to improve my skills.

d.

Affinity Designer 1 & 2   |   Affinity Photo 1 & 2   |   Affinity Publisher 1 & 2
Affinity Designer 2 for iPad   |   Affinity Photo 2 for iPad   |   Affinity Publisher 2 for iPad

Windows 11 64-bit - Core i7 - 16GB - Intel HD Graphics 4600 & NVIDIA GeForce GTX 960M
iPad pro 9.7" + Apple Pencil

Link to comment
Share on other sites

8 hours ago, Ben said:

I'll have a think about it as an option for snapping (since it is only really relevant as an extension for snapping purposes).

Given that the interest seems to be in midpoint and existing edges, and these are basically requests to move either horizontally or vertically by 50% or 100%, would it perhaps be a bit simpler to provide menu options to "Move Up 50% of Height", "Move Left 50% of Width", etc., so that keyboard shortcuts could be assigned?

A set of "move by 50%" arrow buttons could be added to the Transform panel too, perhaps swapped with the anchor point selector (have "tab" type buttons underneath to indicate if the anchor point or the arrows should be shown)...

Link to comment
Share on other sites

This is a feature I very much agree is lacking.

Although it is possible to get the same precision by using the translate pane, this requires clicking and typing outside of the working area, instead of the much faster click+drag&snap around whatever you are working with. I disagree with the need for a ghost, but agree with the fact that when an object is in the midst of being translated, it should snap with its last known position.

sig2.png.950594012af1a9c5582236e0a457cd0a.pngsig1.png.975f263a1c12b5aec3f87a4541eb33ef.png

Illustrator, Designer, 3D Modeller (In that order) - Open for commissions - Check out my art Instagram or follow me on twitter or like my Facebook page. Phew! 

Link to comment
Share on other sites

  • Staff

One of my pet hates is things snapping to invisible stuff - snapping can produce complex enough interactions with stuff that is visible.  So, if snapping to the original position of an object is required, some form of ghost/outline would also be required.  You need the visual cues to make sense of what is happening.

 

As I said before, for the most part alignment to the original position is equally achievable by Shift constraining.  The positioning will still be the same as if applying bounds snapping to the original position, and so additions to snapping achieves nothing new.  The only thing we lack there is alignment to the centre and the edge of the object in the direction of translation.

 

The one area I can see that we don't currently cover is snapping to geometry/nodes of the original positions of an object.  This can't be achieved anyway with the Move tool - snapping of curve nodes can only be done in the Node, Pen and Point Transform tools.  These tools are busy enough, so adding ghost positions is going to need some considerable thought.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

7 hours ago, Ben said:

These tools are busy enough, so adding ghost positions is going to need some considerable thought.

Maybe another option would be to have a "construction mode" feature that dropped an outline of the existing object as a construction object perfectly positioned at its current location, once construction mode is back in the mix?

Then you would be snapping to the construction object instead of to a ghost...

Link to comment
Share on other sites

On 7/15/2019 at 6:43 PM, Frozen Death Knight said:

The way I understood it is that he wants to be able to do things like snap to the mid point of an object's original position the same way as if you had two objects in a document where one object can snap to the other object's mid point. Here's a video demonstration that I believe gets the point across:

Bingo! And thanks for the demo, you saved me the trouble of making it for the time being and got your point across perfectly clear. ;)

By the way, this functionality allows you to make all kinds of snapping operations; it's not just to the mid point(s), but also to the edge points, mid-points on curves, edge paths, everything.

“It just works™.”

Link to comment
Share on other sites

21 hours ago, Ben said:

The one area I can see that we don't currently cover is snapping to geometry/nodes of the original positions of an object.  This can't be achieved anyway with the Move tool - snapping of curve nodes can only be done in the Node, Pen and Point Transform tools.  These tools are busy enough, so adding ghost positions is going to need some considerable thought.

Fair enough, Ben, but this is something the     competition     (I'm not naming them, because I did it already before) achieves already in not too busy a fashion (at least IMHO; I do feel you sometimes worry too much, and if this makes a tool, say, 5-10% busier but the net gains are like 50% faster operations, if not more – and I pretty much guarantee you that I can do some of them as quickly as I'm saying, as I can skip the nonsensical “duplicate–deselect duplicate–delete original” cycle, which can be excruciatingly slow depending on object geometry, position, underlying layer contents, etc. –, your math doesn't really add up), just because they opted on a non-WYSIWYG model by default.

I'm guessing that choice was made back in the day mostly out of technological considerations, because of the hardware's weakness and inherent inability to quickly redraw objects' fills, not unlike window contents in Windows 3.1/95 and Mac OS Classic, when dragging stuff around, but it stuck as a default model in design apps and does offer some crucial UX advantages, as I and others demonstrated…

Nowadays, you can indeed force a WYSIWYG drag operation on most apps, even old-school ones, by clicking and holding before dragging; perhaps AD could offer the reverse behaviour, i.e. offering its current WYSIWYG behaviour and ghosting as an alternative when clicking and holding? That would actually allow you to skip adding yet another checkbox, and if the delay was timed right, it would be easily discoverable, yet forgiving for those who don't want to use it, and quick enough for those who do. Just some food for thought. Though a toggle that might reverse those two behaviours would still be a welcome bonus and fit into the “giving users choice” theme, not unlike you already allow users to opt for a Corel-like (and maybe Plus-like?) selection behaviour, which forces you to fully enclose objects, and an Adobe-like one, which allows you to select objects just by intersecting them.

Sometimes, “busy” is acceptable, or even necessary; if you're working on a busy file, with busy duplication or move operations and their respective snaps, watchagonnado? What I've been telling you for a long time now is that your attempt to make the app less busy is actually having, at least for some users/use cases, the entirely opposite effect (by entire orders of magnitude!) than the one you desired… I know I've been promising demos, and once you see it, you can't really unsee it. I'm so dead sure about this that I'm not even kidding. :P

But yes, I do fully agree with you on the “requiring considerable thought” part, and I'm here to help you with that in any way I can. I have some ideas up my sleeve, and I do believe they can actually look and work better than those of the competition. WYSIWYG models are not inherently bad per se… as long as you don't lose functionality in the process. Which you, indeed, did. ;)

There are many ways to “square the circle”, so to speak, some of them a beautiful compromise, like, say, using translucency as I alluded to before, instead of the, err, competition's insistence on using those positively 80s-ish outlines. And yet, having that “ugly” option, and perhaps even being able to see all nodes on the ghost and the final object's position alike – yes, busy as hell! :D – might be a complete boon for certain users (say, if you want to snap to particular tangency nodes in the middle of a curve, which you otherwise cannot discern? Absolutely!). You should always try to one-up the competition, I'm all for that; but sometimes, it may look better, but actually work worse.

If the user presents a strong case for that, if you can code it, and you're not getting us all into checkbox/toggle-creep hell, by all means go for it. Your Snapping Manager shows great promise and it might be the place where those would reside. Or maybe you could add a “Selection Manager” (because selecting stuff and dragging it around are two inextricably linked tasks) and consolidate all of that stuff there, including the two opposite selection behaviours I've mentioned before and which are currently tucked away in the app's preferences. I dunno, but surely there must be a way to accommodate these kinds of features without disrupting the UI too much. And if it must be a v.2.x feature, so be it, but still; better late than never, and “never” should not even be an option here, as you'll soon see when I show you my demos.

Link to comment
Share on other sites

On 7/17/2019 at 4:57 PM, fde101 said:

Maybe another option would be to have a "construction mode" feature that dropped an outline of the existing object as a construction object perfectly positioned at its current location, once construction mode is back in the mix?

Then you would be snapping to the construction object instead of to a ghost...

I thought of that. But there are cases when this wouldn't make any sense and would add just further operations, when the objective is precisely the opposite.

I'm also aware that some of my use cases for this are better covered by specialised grids (an idea which I love), but sometimes I still stumble upon cases where either the grid wouldn't work, or it wouldn't be worth it to set it up just for that as it would actually take too much time.

Yes, I've thought this through from all possible angles, and I did mess around with grids in Designer. They're great, but sometimes you just want to move some objects around here and there and be done with it.

Link to comment
Share on other sites

  • Staff
11 hours ago, JGD said:

Fair enough, Ben, but this is something the     competition     (I'm not naming them, because I did it already before) achieves already in not too busy a fashion (at least IMHO; I do feel you sometimes worry too much, and if this makes a tool, say, 5-10% busier but the net gains are like 50% faster operations, if not more – and I pretty much guarantee you that I can do some of them as quickly as I'm saying, as I can skip the nonsensical “duplicate–deselect duplicate–delete original” cycle, which can be excruciatingly slow depending on object geometry, position, underlying layer contents, etc. –, your math doesn't really add up), just because they opted on a non-WYSIWYG model by default.

I'm guessing that choice was made back in the day mostly out of technological considerations, because of the hardware's weakness and inherent inability to quickly redraw objects' fills, not unlike window contents in Windows 3.1/95 and Mac OS Classic, when dragging stuff around, but it stuck as a default model in design apps and does offer some crucial UX advantages, as I and others demonstrated…

 

This isn't a question of WYSIWYG tooling.  This is primarily the question of predictable behaviour with clear visual cues.  Snapping to invisible objects is a nightmare - they can easily interfere with expected behaviour.  That is why I say snapping to the original position of an object without a clear visual cue is not good.

 

This also has nothing to do with technological considerations - you are off the mark there.  It is 100% down to the reason I give above.

 

I'm also going to argue against your "50% faster operations".  What you mean is a 50% faster operation for the one use case you describe - which is actually not a very common operation for most people (given that we haven't had many calls for this behaviour in the 5 years since release,).  Beyond constraining a translation to the original position of an object (which can already be achieved by holding Shift) the operation you require is to be able to snap to some demarkation of the object's original position that cannot be determined through constrained motion.  Specifically, the main operation is snapping to the centre or opposite edge of the original position of an object while also not making a duplicate (else the original object is still available for snapping).  These are the only target positions you'd be able to achieve with bounding box snapping.  This is actually a very specific use case when considered against the existing functionality available, and I'd argue (while you say it will be useful to you) whether it justifies compromising the 999 other use cases that people more regularly have?

Specifically, your use case (as far as I can ascertain) is the need to snap to the bounds of an object's original position while having no other objects present providing the same alignment, and that cannot be made through just constrained translation.

 

I understand the mechanics of what you are asking for, but can you please elaborate on a real world example for this use case.  I mean - where you would use it many times, in order to justify not using the clone-delete method described by others.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

  • Staff

I will just describe a counter use case to what you are requesting - that I know is common.

 

I have a document with a layout of fairly regular objects.  I want to correct minor errors in the positioning of a couple of objects that are almost in line with the rest.  I rely on bounding box snapping for this.  I move an object to allow snapping to pull it into perfect alignment (this might be while also Shift constraining to one axis of movement).

If snapping also took into account the original position - I'd end up fighting between snapping to that position and the position I actually want.  I'd then have to look carefully at the snapping overlays to ensure that the position is snapping to my intended target and not the original position.  This operation then becomes more difficult due to having a rogue snapping target - in fact the very position I am trying to correct away from.

 

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

@Ben I have a suggestion. What if Guides allowed you to do this action instead, and they followed the object automatically as you finished moving, scaling, and/or rotating it to a new position? I made a quick video showing what I mean, but instead of dragging the lines manually, they adjusted to the dimensions of the object based on its maximum size both horizontally and vertically. If this specific type of Guides worked on a layer per layer basis it could potentially solve the issue without the need of a "ghost object". Do you think this could work instead?

Link to comment
Share on other sites

  • Staff

How exactly do you associate guides with an object?

 And if the guides are part of the object, don't they still move with the object anyway (as it is being moved, I mean). So what are you snapping to - the original position of the guide again, before you started moving it?  Sounds like the same issue to me, just being made more complicated.

 

No - not sure this is a solution.  And if it still only addresses this one very specific use case, it is not a justification for adding a whole lot of complicated functionality.

 

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

1 minute ago, Ben said:

How exactly do you associate guides with an object?

 And if the guides are part of the object, don't they still move with the object anyway (as it is being moved, I mean).

 

No - not sure this is a solution.  And if it addresses this one very specific use case, it is not a justification for adding a whole lot of complicated functionality.

 

I don't know since I am not a coder, which why I asked you. If it can't be done, then that's unfortunate. The only solution I found was to duplicate the same object multiple times and then prepare the document with guides that match the size of the object. One thing that makes this less practical is that you can only select and move one guide at a time.

If I was able to select all of the guides at the same time and move them simultaneously on the canvas this would be more effective.

Link to comment
Share on other sites

  • Staff

I don't think using guides achieves anything different to cloning an object and deleting the original. If anything the clone-delete method is potentially faster than using guides.

 

Like I say - defining special behaviour for guides is not going to happen - it would require too much tool development for no real gain.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

On 7/18/2019 at 4:14 PM, Ben said:

This isn't a question of WYSIWYG tooling.  This is primarily the question of predictable behaviour with clear visual cues.  Snapping to invisible objects is a nightmare - they can easily interfere with expected behaviour.  That is why I say snapping to the original position of an object without a clear visual cue is not good.

This also has nothing to do with technological considerations - you are off the mark there.  It is 100% down to the reason I give above.

Ok. Let's start by this point: you can't absolutely speak for the competition. I would bet a kidney that Adobe et al. used a non-WYSIWYG object dragging model in the 1980s because of technological limitations. As for you, I'd also bet that you started with a WYSIWYG model, first and foremost, because you could and that was the expected behaviour in most OSes for dragging operations (everything is WYSIWYG now; icons, windows, etc.), and then rationalised your choices (and did some heavy testing, yes) to make sure your model worked as best as it could. But you did keep it too simple and, indeed, threw the baby out with the bathwater, sorry. :|

But let me focus on this snippet for a while:

On 7/18/2019 at 4:14 PM, Ben said:

Snapping to invisible objects is a nightmare - they can easily interfere with expected behaviour.

Are you referring to the “expected behaviour” from a user standpoint, or from your standpoint as coders? Anyhoo, I digress. I never intended to propose “snapping to invisible objects”, never in a million years, and if my phrasing came out as such, I'm sorry. Let me get this clear, once and for all: when I speak about “ghosts”, I speak about visible objects, in their original position but clearly depicted as “ghosts” (since the opposite would be rather similar to the competition, and, yes, non-WYSIWYG in the sense that id wouldn't show their final placement with the actual, predictable final looks after releasing the mouse), because they are a trail being left behind which will soon disappear. Do you know those racing games, where you can race against your translucent self[ves] in time-trial mode? That's the kind of “ghosts” I'm talking about. ;) 

Ben, like Professor Brandão, I'm not some ignoramus, either. As I've said before, many times, I do not hold a degree in UX nor ever coded an app of my own, but I've been playing with software for 27 years now and specifically with design software and reading on the subject for at least 19. I studied Ergonomics during my BFA and first MA, and I know what affordances are; I know what UX forgiveness is; I know how visual cues work. I even had to endure entire semesters on subjects such as communication theory, semiotics and visual perception. And recently I've been reading on really advanced visual cognition science stuff, i.e. Hofstadter et al., for my MA dissertation. I know how this stuff can cascade rather quickly into an unusable mess if improperly implemented, and I would never suggest something as… ridiculously unintuitive as a visually unpredictable interaction model. So yes, I know this would be busier, with smart guides popping left and right and whatnot (even more so than they do already, yes xD ), but  everything would be visible and predictable at all times.

On 7/18/2019 at 4:14 PM, Ben said:

I'm also going to argue against your "50% faster operations".  What you mean is a 50% faster operation for the one use case you describe - which is actually not a very common operation for most people (given that we haven't had many calls for this behaviour in the 5 years since release,).  Beyond constraining a translation to the original position of an object (which can already be achieved by holding Shift) the operation you require is to be able to snap to some demarkation of the object's original position that cannot be determined through constrained motion.  Specifically, the main operation is snapping to the centre or opposite edge of the original position of an object while also not making a duplicate (else the original object is still available for snapping).  These are the only target positions you'd be able to achieve with bounding box snapping.  This is actually a very specific use case when considered against the existing functionality available, and I'd argue while you say it will be useful to you does it justify compromising the 999 other use cases that people more regularly have?

On this point, I'm very sorry I can't provide you with a “silver-bullet” demo right now that would completely and incontrovertibly sell my case. I could provide you with a workable proof-of-concept demo right away, but judging from what I've read, I'm sure you'd shoot it down because it would be “little benefit for too much work”. But sometimes I'm using Ai and the thought “I couldn't absolutely do this at all in Affinity Designer without wanting to defenestrate my Magic Mouse 2 and gnaw my own hands off” crosses my mind, so as soon as I hit one of those use cases I'll whip up a quick demo and post it here (and rest assured, since I have some free time now, and will be preparing some type design workshops very soon and giving them in October, that will likely happen sooner rather than later… And if I do have the extra time, I'll scour old files to see if I can find one of those examples a bit quicker). And only then, I'm guessing, will you have enough material to discuss it in an internal Serif meeting, which is perfectly reasonable because you do have a lot of stuff on your plate right now and should prioritise stuff heavily, yes. But I'm really that confident that you will, and that I'm making a strong case of a high cost-to-benefit ratio feature.

But I will stress something important here, regarding your second-to-last statement: of course I'm not suggesting that the only use case for that would be bounding-box snapping. Nope. That would be kinda useless (and, for that, sure, maybe using guides or some other workaround might make sense, except you've also debunked that for me already). I mean all kinds of snapping (nodes, edges, centre-points, mid-points, the works). Snapping any and everything to any and everything else, between ghost and final position. And since the “ghost” will be visible, its functionally won't be any different from duplicating and dragging, except the “pseudo-duplicate” (i.e. ghost!) goes *poof!* after the drag operation. I mean, this much should have become obvious by now, and if you ever test it (like, say, in the aforementioned competition, but if you ever wish to code that for yourselves you'll realise the result is the same), you'll realise it's not nearly as unintuitive or busy as you're painting it. I know, because I've been using that object dragging interaction model since 2004 with nary an issue.

On 7/18/2019 at 4:14 PM, Ben said:

Specifically, your use case (as far as I can ascertain) is the need to snap to the bounds of an object's original position while having no other objects present providing the same alignment, and that cannot be made through just constrained translation.

Exactamundo. Except, as I've said, it's not just the bounds. We've been talking about “bounds”, because the easiest example object we've all been using is the simple, boring rectangle, whose bounds match its outline, hence your confusion. I don't really care about bounds, as those are always orthogonal and, more often than not, do not match the stuff I want to move and snap around. This gets way more complex and interesting when we start dealing with polygons and other regular and irregular shapes.

You see, this is where I've been getting at for years now; you're thinking about AD and my – and other's – proposals too much from the lens of a developer catering to freehand, Wacom pen- and Apple Pencil-wielding illustrators, and it shows. For precise, geometry stuff, AD really does have some severe shortcomings, this one being one of them.

I just so happen to be the leading expert in my country, and probably one of the top-10 in the entire world (at least judging by currently and prospectively published work; you did get to the part where I was invited to publish my dissertation in book form, am I right? I take it that it will be published in Portuguese first, but I will push heavily and ask for enough financing for it to also be translated into English ASAP; that's how much I trust my own work, as I never took it as just another chore to get a diploma, but as a labour of love with a very specific, almost political goal in the world of type design and teaching in particular), on modular geometric typography. I live and breathe geometric shapes. And I love grids, as you've probably noticed already. But until you implement advanced tesselation grids on your app(s) (which I seriously doubt you ever will, and it doesn't bother me either way, as those are as niche and hard to implement as they get and the end user can pseudo-implement them anyway by using pattern tools already), they can only take you so far, and even then, when I'm dealing with a simple isometric or even orthogonal illustration or typeface, if I'm doing an academic poster, publication or even geometric illustration with stuff based on several different grids, I won't be setting up any particular one – because of the obvious mismatches that would ensue – and would at least expect my vector drawing app to make life a bit easier for me.

Link to comment
Share on other sites

  • Staff

Just to be clear - our bounds are not just rectangles.  If you have investigated our advance grids system, you'll see that bounds are the limits of an object with respect to the axes of the current grid.  We only present a rectangle for ease of common transformations.  You'll notice that can become a parallelogram when transformed or selecting an object with shear.  Snapping during translation always conforms to the current grid axes, and not the visible selection box.

 

As far as your WYSIWYG issues go - I think I'm loosing your actual point in the avalanche of too many words.  How about some concise and short examples of what you mean?  I also don't understand your objection to being able to see the immediate effect of tools.  This to me is far better than outlined changes with delayed real updates.  Too much visual clutter beyond what is needed is often a fine balancing act.  It also depends heavily on what discipline you are in when using the tools.  For technical drawing, lots of information might be useful.  For free illustration, not so much.

 

Believe it or not, some of us on the development team here also have some qualifications and experience, and from a wide range of disciplines.  I think cumulatively it will be running well into centuries.  Opinions on usability are affected by user experience and knowledge.  We have to make our tools to accommodate all levels of expertise - not just those who consider themselves elite in the field.  Our choices aren't driven by coding considerations first - but limitations of interface and hardware are always going to have to be a consideration.

 

I'm also afraid that after explaining everything, that silver bullet real world example of what you are asking for is the only thing that is going to motivate us to put work into this.  I think I've shown that there is only one specific use case that we are not covering, but I am not convinced of the weight of need for this use case without real evidence.  You claimed it is "critical", so you must require it frequently enough that a real example should be easy enough to find??  Beyond this, all the very verbose philosophising is really leading nowhere.  This applies to all requests - give an actual example with use case, and we can make some sense of it.  And keep it concise - all the excessive noise, personal claims and soap-boxing in these threads is distracting from any relevant point that might be hidden in there.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

7 hours ago, Ben said:

Just to be clear - our bounds are not just rectangles.  If you have investigated our advance grids system, you'll see that bounds are the limits of an object with respect to the axes of the current grid.  We only present a rectangle for ease of common transformations.  You'll notice that can become a parallelogram when transformed or selecting an object with shear.  Snapping during translation always conforms to the current grid axes, and not the visible selection box.

 

As far as your WYSIWYG issues go - I think I'm loosing your actual point in the avalanche of too many words.  How about some concise and short examples of what you mean?  I also don't understand your objection to being able to see the immediate effect of tools.  This to me is far better than outlined changes with delayed real updates.  Too much visual clutter beyond what is needed is often a fine balancing act.  It also depends heavily on what discipline you are in when using the tools.  For technical drawing, lots of information might be useful.  For free illustration, not so much.

 

Believe it or not, some of us on the development team here also have some qualifications and experience, and from a wide range of disciplines.  I think cumulatively it will be running well into centuries.  Opinions on usability are affected by user experience and knowledge.  We have to make our tools to accommodate all levels of expertise - not just those who consider themselves elite in the field.  Our choices aren't driven by coding considerations first - but limitations of interface and hardware are always going to have to be a consideration.

 

I'm also afraid that after explaining everything, that silver bullet real world example of what you are asking for is the only thing that is going to motivate us to put work into this.  I think I've shown that there is only one specific use case that we are not covering, but I am not convinced of the weight of need for this use case without real evidence.  You claimed it is "critical", so you must require it frequently enough that a real example should be easy enough to find??  Beyond this, all the very verbose philosophising is really leading nowhere.  This applies to all requests - give an actual example with use case, and we can make some sense of it.  And keep it concise - all the excessive noise, personal claims and soap-boxing in these threads is distracting from any relevant point that might be hidden in there.

Ok, Ben, I'd love to go through your answer, but I must run because I'm finally having some really “free” time (as in… mentally free, or more specifically as in having actual vacations after four years :D ) and feel like, you know, not touching “work” for the time being. The quality of my feedback would be sub-par if I were to take on this right now, and you deserve better than that. Besides, this isn't the most urgent of Designer's limitations, though it is a little pet peeve of mine and would really make a world of difference in my future work.

Anyway, you did raise some very interesting questions, which I'll address later on, point by point, in a structured post, maybe even with some comparison screenshots/mockups, so we can all get on the same page. Call it a “white paper”, if you will. I will also try and do my best in some short, concise demos (be they silver, gold, copper, tin bullets, whatever)… Maybe over the weekend, or in late July/early August. Stay tuned. :) 

Link to comment
Share on other sites

  • Staff

@fde101 are you feeling my pain? ;)

 

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

  • Staff

I'm considering rejecting any post with a word count over 100.

SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.