hifred Posted February 11, 2019 Posted February 11, 2019 The more I tinker with Affinity Photo, the more I run into bad, but quite easy to fix traps. Some of them are caused simply by the fact that a tool behaviour remains stuck the inappropriate positions, so that they block editing in later stages of the project. Here's two: 1) Recently I found out that selection-tools stubbornly remain stuck to their previous Subtractive state even if the user wants to create a fresh selection. The operation fails, although the user has picked the appropriate tool and also has performed the expected motion. Here one badly needed an exception to the rule – selection tools have to create a selection if the tool can not find anything to subtract from. Others suggested that Affinity should beep or show a dialog and by that inform + CTA the user that the tool is in the wrong state – but that would be horrible UX. At that point you could also abolish your assistants too. Don't make me think, don't ask for pointless decisions and action if there's exactly one expected behaviour: Making a (fresh) selection. 2) Today I saw another thing which is even a lot nastier as there's not even a suble visible indicator. One may hide selections (hide the marching ants), which is great. But that hidden state even remains active when the user wants to create a new selection. Such really may not happen. There's absolutly no workflow imaginable where this made sense, this is just a trap and nothing else. A hard to understand trap – imagine you had a selection hidden and go to lunch, afterwards you pick a selection tool and run into what's shown in the GIF. Selection tools always have to revert to state=visible whenever a selection is dropped. Is there anyone in charge, exclusively for little usability-killers of that kind? It would well be worth it. Quote
Staff Gabe Posted February 11, 2019 Staff Posted February 11, 2019 Hi @hifred, I have moved this to feature requests as neither of your examples are bugs. The first one has already been explained in the thread you quoted, while the second one is not a bug at all. If you choose to hide the selection, the app will hide it, regardless of any tools you're using. If it were to show the selection when you had the "show selection" off, then it would have been a bug. Thanks, Gabe. Quote
hifred Posted February 11, 2019 Author Posted February 11, 2019 22 hours ago, GabrielM said: I have moved this to feature requests as neither of your examples are bugs. Well, this is a matter of definition. I only wrote about malfunctions in existing features. I consider standard-tools which bring users to a point that they can no more track down the issue themselfes defective – as the present tool-behaviour does not offer the slightest advantage, in any context. Jowday 1 Quote
hifred Posted February 12, 2019 Author Posted February 12, 2019 Here's one more – this has not to do with inapropriate tool states causing irritation – but a lot with getting trapped. Affinity Photo lets us embed external images and layered documents, which are not rasterized and therefore may get losslessly transformed. As a consequence the layer isn't directly editable with tools which require rasterized data. Understandable as well. What is not understandable and what again makes perfect traps for anyone who knows similar features from other applications is that one on embedded content... cannot create raster copies from selections may not apply sort of pixel based manipulations/corrections on layers above (stamp, heal, blur...) Right now all these operations just fail and the program gives zero feedback why this happens. Altogether these make for dozens of possible situations where nothing happens on screen and users – especially those coming from Photoshop – have no idea what the heck could be wrong. The very first step in the right direction would be that you showed an info that you that the source layer needs to be rasterized. The actual solution was to avoid such situations altogether. Other programs perform instant rasterization for the required operations, so that one may retain the encapsulated object as is and still manipulate it at will – on layers above. This auto-rasterization has only advantages over what Affinity Photo does currently. What certainly is not helpful at all is to rasterize the external content via (default) assistant – without even asking. But that's actually happening. Is there btw. already a way to send embedded documents to external applications for further editing? I have not found how to do this. I also updated embedded documents with 3rd party apps but Affinity Photo neither auto-refreshed the embedded file (seemingly no no embed + link functionality) nor lets me perform the update manually. Have I overlooked anything? Quote
Staff Gabe Posted February 12, 2019 Staff Posted February 12, 2019 27 minutes ago, hifred said: Is there btw. already a way to send embedded documents to external applications for further editing? I have not found how to do this. I also updated embedded documents with 3rd party apps but Affinity Photo neither auto-refreshed the embedded file (seemingly no no embed + link functionality) nor lets me perform the update manually. Have I overlooked anything? I'm afraid no. You cannot send embedded documents from Affinity to 3rd party apps. Also, embedded documents to not dynamically update. We hope to have live sync in the future, but we do not have an ETA at the moment. Sorry Quote
hifred Posted February 12, 2019 Author Posted February 12, 2019 19 minutes ago, GabrielM said: You cannot send embedded documents from Affinity to 3rd party apps. Also, embedded documents to not dynamically update. We hope to have live sync in the future, but we do not have an ETA at the moment. Sorry Thanks for letting me know Gabriel. External editing of embedded docs would also be extremely useful for those, who prefer using 3rd party tools to edit their RAW files. One would win a lot when Affinity Photo displayed processed RAWs as embedded documents, for compositing with other content and let us jump to 3rd party tools for further tweaking. In the same way I hope you guys implement re-editing RAWs inside the upcoming Serif-DAM... Quote
hifred Posted February 13, 2019 Author Posted February 13, 2019 And yet another one in (APhoto) Fill Layers ➜ see also here Create a Fill Layer, fill with any solid colour Select the Fill Layer Pick the Brush Tool and start painting, to create a mask Now try to change the colour of the Fill Layer The operation fails, as Aphoto, with the Brush tool active assumes that one wants to change the colour of the brush. Users at that point will very likely believe that the fill layer had gotten rasterized and that one no longer can interactively change its colour. Indeed the Fill Layer remained intact – one 'only' needs to change the active tool to any other tool which doesn't paint and therefore has no colourpicker hooked up. What's bad about this? You leave it up to the user to unnecessary deeply analyze the work scenario and to deliberately establish matching conditions for the Fill Layer colour-change to work. Photoshop demonstrates how such situations may get avoided, by Design. To change the colour of the Fill Layer the user has to explicidly address a colour swatch inside the Fill-Layer. This may happen with any tool active. The user disambiguates, without having to think – how nice. Quote
hifred Posted February 13, 2019 Author Posted February 13, 2019 This one deviates a little from previous reports, but as one inside Affinity Photo doesn't get a visual in the image or indicated in the Layer-Editor / Status-bar info about resolution-headroom I think this is a UX flaw as well. When I place an high res image (i took a huuuge 42MP jpg) as an Image-Layer into small APhoto document I get a preview, which quite obviously shows at greatly reduced resolution on screen. As soon as the document Zoom Level exceeds 100%, one runs into pixelation. With the document open one therefore has no way to judge the true quality of the placed image. This is a crop from a huge image – but it appears in poor quality in Affinity Photo. The user gets not even a readout somewhere, which informs about its actual quality. What I found most user-friendly /wysiwyg in this situation would be screen-rendering which reveals the actual resolution of each element in a composition. Vector elements and text should render crisp at any magnification level, as it is the case in Affinity Designer + Publisher. Images with low resolution should show their limits sooner, while high res images remain crisp, even at higher zoom levels. There may be good technical reasons which do forbid hooking things up that way, but I wonder what these are... The very unfortunate effect of the current method is that one with placed images in compositions (and generally when working with text and vectors in Affinity Photo) only can evaluate the final quality level in the exported image. That seems very wrong to me, conceptually. Ironically both non image-specialized Affinity programs (AD, AP) do display placed images at full resolution (obviously text and vectors too). AD has no problems with full res images in the Pixel-Persona too...Should there really be absolutely no way around using the current screen rendering methods inside Affinity Photo (which I heavily doubt and loved getting an explanation for) the absolute least that should happen was, that one was given some clear indicators, that one is not looking at the final quality level. Photoshop, in my very old CS6 version doesn't excel in this respect either* – the placed image appears at low resolution too. But one can doubleclick the image (Smart Object) in the Layer stack, to open it at full resolution in a new tab. That way one can at least make sure, that one is working on the correct file. Xara always displays the resolution at the current scale in the document, which also helps. Interactive display of placed content's resolution in Xara's Layer stack *that may have changed in the meantime Quote
hifred Posted February 15, 2019 Author Posted February 15, 2019 Hi @Mark Ingram Here I have piled up and explained a few other UX issues. They all, without a question fall into the "changing the default behaviour of the application is a thing which we rarely want to do" realm :o) It took some time to collect and maybe you find some of this not too foolish after all... I'd be happy if you / the UX guys had a look, before the the thread gets burried in this ever growing feature-requests-thread. Mark Ingram 1 Quote
Recommended Posts
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.