Jump to content

Medical Officer Bones

  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

2,667 profile views
  1. @PΕ‘enda That is why I wrote that the only way to figure this out is to test, test, test, and compare various versions with small groups of participants. Because conversations like these tend to run in circles. That's an interesting thought - I actually think I prefer the non-standard version. πŸ˜„ Never considered that before. It seems easier to check which page number belongs to which content inventory entry and the eyes do not have to wander across the page from left to right and back again. Because of the indentation of each entry the page number on the left simplifies tracking each item as well. In particular for the first 7 entries the left-aligned version is by FAR easier to understand which roman number belongs to which entry. Traditions in layout are not always right, it seems. πŸ˜‰
  2. Have you actually put them side by side to compare? The left version is simpler to visually navigate than the right one. And at least to my eyes and brain I have much less difficulty figuring out the visibility state of the layers. Also: Users are apt to use and work in documents with less groups rather than more. This is an important one to keep in mind. Your example is an outlier situation with that many nested layers - and you actually provide a reason against a right-aligned version in that the more nested layers there are, the more you need to widen the layer panel window and thereby increasing the distance between the parent layer(s) and the layer visibility checkbox. In short, extreme use cases like yours do not provide for convincing counter arguments against common use cases. Target the common ones, and provide contingency GUI solutions for extreme cases - not the other way around as your thinking goes. You fail to include layer effects and layer lock icons. These create more noise on the right, and as I mentioned before functionality is probably better separated with the left version. Having the checkboxes on the far right also creates more issues than solutions, which is beautifully demonstrated by your own screenshot of disappearing content forcing the user to either scroll or increase the width of the layer panel - which further increases the distance between the checkbox controls and the base content layers. I agree that horizontal scrolling should be possible - and in that case again it makes more sense to use the left aligned checkboxes: those would then stay locked in place, while the user is able to scroll the content to the left - reducing distance rather than increasing distance between parent layer(s)s thumbnails and checkbox. The left aligned version adheres to the Western left to right reading order. Going against that creates cognitive friction in a user (this is proven in usability and readability research). The checkbox on the left provides a visual anchor for the user to follow downward, which is not the case on the right. Or let's use another example. Would you prefer bullets on the left or on the right? Most users probably prefer having these on the left. Why would you go against common accepted proven practices? From the point of view of scannability and proximity, as well as common use cases, left aligned would work better in my opinion. But again: only proper testing with actual users and various use cases will yield insight which will work better. And thank you for pointing out all the other usability issues/inconsistencies with the layer panel. In my opinion the layer panel deserves a bit of rethinking.
  3. A 1-bit image mode is not supported in Affinity Photo or Designer - or Publisher for that matter. The developers have stated that 1-bit support will never be implemented in Affinity: There have been quite a few threads created about the lack of 1bit mode support in Affinity. Iffy work-arounds abound such as the threshold filter suggestion above, or adjusting the layer blend. None of these are great, unfortunately. As always, if this is a requirement in your work, I would suggest PhotoLine, which not only supports a proper 1bit image mode like Photoshop, but goes beyond Photoshop in that it allows for layers while working on 1bit images. It is also possible to export your vector line art/inks from Designer to PhotoLine and convert these to high resolution 1200ppi 1bit images. PhotoLine also allows for proper 1bit high resolution PDF export and can be used to combine cmyk/rgb artwork with high resolution 1bit imagery for this particular task too.
  4. @N.P.M. I forgot about this one as well (I prefer to hide and show things by key shortcut): Cinema4d puts these to the right as well (which are really awkward to work with, btw). Then again, when animation timelines are present the visibility controls are always invariably placed to the left of these - including Blender and C4d. Which makes sense, of course within that context. Perhaps I should have written image editing/digital painting/video editing/ 2d animation / audio editing software instead of design software? πŸ™‚ Gimp, Photoshop, PhotoLine, Corel Paintshop Pro, Corel Photopaint, Photopea, Toonboom, OpenToonz, Krita, ClipStudio Pro, Animate CC, TVPaint, After Effects, ProMotion NG, Premiere, Davinci Resolve, most pixel art editors... Pixelmator on the other hand again on the far right. Which shares its origin on the Mac with Affinity (perhaps it is a Mac GUI guideline the developers followed? But Apple Motion places these to the left...) *edit* Nope, Paint.net does the exact same thing as Affinity Photo and that is Windows only! And you are correct: I also forgot about Inkscape and Xara.
  5. A properly conducted usability test should provide useful insights here. From a functional perspective, speaking for myself and from observations of students while working in Photoshop, hiding and showing layers is an action performed many times more than locking a layer or opening the layer effects via that icon. I stand by my hypothesis that moving the visibility function to the far left will allow a user a more convenient and efficient workflow. At the very least Affinity is (as far as I am aware) the only design app that positions the layer visibility function to the far right, which does seem to go against most designers' conceptual model that they created based on prior experiences with design software. Notice that Capture One (example posted earlier in this thread) also sticks to this convention. In UX design it is considered bad practice to break accepted conventions unless that new approach affords a clear advantage over the older method. In this particular case I struggle to see such benefits, and it is rather obvious what the disadvantages are. From personal anecdotal experience, when I work in Affinity Photo I notice that I am slowed down by that right aligned checkbox. As for the exact reasons? Well, that is why a simple usability test would bring some clarification in this matter πŸ™‚
  6. The layer stack UX design is indeed problematic, and it has less to do with the choice of a checkbox as an indicator for layer visibility, and more with the positioning of the checkbox to the far right of each layer row. Placing the checkbox near the right causes a number of issues: users tend to focus on the thumbnail and/or layer name to identify the layer they would want to select or work with. Because the visibility checkbox is located to the far right, it is impossible to tell in one glance whether one or more layers are visible: first the user checks the thumbnail or layer name to identify the layer, then the user's eyes must follow the layer row to the right to check if that layer is visible or not. Our eyes can only focus on a very small area and see details. In this particular case it is biologically impossible to identify the contents of a layer via the thumbnail AND identify whether that layer is visible or not. This is not an issue in other design software, because the visibility icon/indicator is always placed directly left to the thumbnail. Vice versa, it is also problematic when the user needs to identify which layer contents belongs to a hidden layer. First the eye must identify the empty tiny checkbox, then follow the layer row to the left. This action is problematic not only because of the aforementioned issue, but also breaks a common rule that Western languages are written from left to right: to move from right to left with our eyes to identify information breaks that basic rule and causes cognitive friction. The above issue is exacerbated due to the tiny checkbox: the on/off state is not clear enough. It takes true cognitive effort to visually identify which layers are visible and which are hidden when a number are hidden and others are visible. Our brain is forced to jump right to left and left to right in the layer stack for each layer, and up and down, double-checking along the way - rather than a simple downward traveling eye movement, capturing both the content and the visibility state simultaneously. An additional issue is quickly identified when layers are locked and layer effects are assigned: those icons are also placed to the right of each layer stack row. There are multiple issues with this: for one, the meaning of the checkbox becomes ambiguous: is the layer FX active or inactive? Or the lock? More problematic however is the cognitive noise that occurs: our brain is forced to differentiate between these various icons near the right, increasing cognitive friction. One more issue is that the layer visibility checkbox is placed to the far right and the lock and fx icons to the left of that checkbox, creating an additional visual obstruction for the eye to travel to the left over the layer row to check which layer contents it belongs to. It all adds up to a rather high cognitive effort on the part of the user. From a function perspective the layer visibility and layer properties (lock, fx, blending, opacity, etc.) are distinct and separate. Placing both the layer visibility indicator in the same area as the layer properties only serves to create more cognitive friction and noise. The two should be kept separated. When layers are selected the checkbox colour is kept: a light gray. But the selection colour is a light background blue. In this context it becomes quite hard to visually differentiate between layers that are selected and identifying which are selected and which are not. Yet another hurdle to what should be a simple cognitive task. Placing the visibility indicator to the left introduces a visual cue that organizes the layers better when multiple embedded groups are present in the layer stack. It is well known that readers have trouble understanding a paragraph of text that is set to ragged right aligned (left to right languages): it vastly reduces readability. It could be argued that without that stabilizing visibility icon column the users' eyes are forced to follow the indented groups - further reducing visible understanding of the layer stack. placing the checkboxes to the far right does not seem to be consistent seeing that checkboxes in the Effects panel are placed to the left - which is more readable, of course. And which then brings to the fore: for what rational reason did the developers decide that placing these checkboxes to the far right would be a good idea? Because they obviously felt that it is more natural to place these to the left of the effects entries. when the user widens the layer panel horizontally, placing the tiny checkboxes to the right begins to make even less sense. Fitt's law anyone? Why make life so hard for your users? Which brings up the last point: should checkboxes have been used in the first place to indicate layer visibility? A checkbox basic meaning is "(not) active", rather than "(in)visible". An argument could be made against the use of a checkbox to indicate visibility, again from the standpoint of consistency: the aforementioned Effects panel seems to use checkboxes within the context of "an effect is either active or not". The meaning of a checkbox to indicate layer visibility seems somewhat ambiguous then. In particular seeing that in most design software with a layer stack an eye icon is used, it seems preferable to yield to common sense and accepted UI practices and accept the prevalent conceptual model, i.e. the eye icon. All of which means this: It is quite problematic to the user to figure out which layer is visible, and which is not. Even harder to understand which layer contents belongs to which visibility indicator. Our eyes are forced to jump all over the place. Time someone other than yourself and ask them to identify which layers are visible and which are not. Simply moving the checkboxes to the left and inverting the colour for selected layers resolves many of the above listed issues: Now perform the same test with a bunch of users. Time them again. I expect that the result will be thatit is FAR easier to complete this simple test with the second version. In my opinion the Affinity devs have never properly tested the user experience, and merely went by gut decisions, or whatever. There exist a number of additional usability and functionality issues with Affinity Photo's layer stack; customized blend options assigned to a layer are not indicated by a visual cue in the layer stack it is not possible to drag over the visibility indicators (check boxes) to hide or show the content of layer in one motion opacity value is not indicated only three settings for thumbnail size no option to alt-click visibility indicator to hide or show selected layer only (it is really different behaviour compared to the Solo mode) layer colour tagging: similar issues related to the fact that the visibility indicator is positioned to the far right. Colour tagging again is more useful and easier to identify when pushed closer to the actual content thumbnail. Moving the checkboxes to the left is "low hanging fruit". It simply improves usability and UX.
  7. Untrue. It brings something to the table for web image usage that neither PNG nor JPG supports: a lossy image format with full transparency support. It was sorely needed.
  8. I remember Carrara back in the 90s - even at that time it was a bit of an outlier. It had potential, but it just couldn't compete very well. It is extremely outdated for 3d software. Serif would have to rewrite the core of Carrara altogether to allow it to compete and that is never going to be lucrative: Blender's usability has jumped ahead by leagues in the latest versions, and is now quite easy to get into for a beginner. And obviously Blender is light years ahead of Carrara in terms of functionality. Carrara belongs in the archives of old defunct 3d software, unfortunately. I am amazed that Daz is still selling it for $285! But it seems they actually merely selling their 3d assets and Carrara happens to be part of that deal. It's not even compatible anymore with Mac Os. Serif would be sinking cash in a very VERY deep money pit. It would be preferable for Serif to acquire LightWave instead (but that's going to have a really tough time competing with Blender as well...).
  9. Yes, absolutely agree with you in regards to the text tool in Krita. The devs should really up the ante there. I still prefer InDesign for that work myself: the typography is so controllable. Although I have been doing more lettering in PhotoLine the past few years - in particular because it also supports 1bit image layers combined with different resolutions and bit depth combined in the same layer stack. Also not a fan of lettering in ClipStudio, btw, because it is originally aimed at Japanese comic lettering, and a bit too clunky for my taste. PS didn't you like Krita's colorize mask tools? I have used those before to create the holds quickly, and export the layered result to Photoshop/PhotoLine. Saves myself hours of manual tinkering with selections.
  10. @LDB Completely agree. I would actually argue that Photo is entirely unsuitable for use in a professional comic colouring and publishing workflow. The gradient tool is utterly unusable for colouring work, but there are other problems, such as the lack of an overfill option to speed up flats and holds. Since you seem to be in a discovery phase to replace Photoshop for your comic colouring work: have you had a look at Krita and/or ClipStudio? Both have a dedicated set of tools to simplify comic colouring work. Krita in particular offers a very efficient Colorize Mask workflow to create flats quickly and efficiently - with automatic gap close hinting and cleanup. And automatic colour swatch tracking of the colours used for flats! No more manual selections for everything: add a stroke to indicate the flat, and done. It may take Krita some time to calculate the flats, but still way faster compared to manually creating selections and filling those. https://docs.krita.org/en/reference_manual/tools/colorize_mask.html?highlight=colorize
  11. Instead of focusing on that static 3%, consider the trend: 600% increase in only 11 months. And before that almost no usage of WebP. In any case - we will know in another 11 months
  12. @LondonSquirrel I feel you are missing the overall trend of webp usage and popularity. I see a parallel trend with WebP compared to SVG. It took SVG a LONG while before it finally took off - but when it did... What I find most interesting is that it took SVG 4 years, more or less, to get where WebP arrived at in only 11 months time. The 600% increase in this short time is quite telling, in my opinion. While it is still early days, I expect WebP usage to at least triple in the next 12-16 months. We see that at this point that 8.2% of the top 10,000 sites use WebP for image delivery. Which makes sense: bandwidth costs money, and WebP saves bandwidth. But also because developers of the top segments tend to be more forward-thinking to remain competitive. Another reason why I forecast a dramatic increased uptake of WebP rather sooner than later. And very simply for smaller websites it means faster loading times and an improved user experience. These things, and the increased awareness. In my classes more and more webp is used by the students. Most design software can now export WebP, even if it requires a plugin (looking at you, Adobe!). The genie is out of the bottle. It is up to the Affinity devs to keep up with these developments and obvious trends. If not, they'll be left behind.
  13. The main issue is that "industry standard" design and animation software still do not support the export of webp. It's a bit of a chicken and egg situation. Luckily the situation is changing: Krita 5 supports both APNG and animated WebP files, as does PhotoLine. Plugins exist for Photoshop to do the same. And WebP is gaining popularity. Simply stated: things are possible with WebP that are not possible with (A)PNG or other file formats or coded solutions that eat up much more bandwidth. This has an impact on the user experience from both the perspective of load times as well as eye-candy, and as such, it is steadfastly growing. As a large web-based business you'd be plain losing money on bandwidth if you keep ignoring webp. @LondonSquirrel You seem to ignore the fact that the uptake of webp grew by 600% in 2021 only, and that it is the most popular image file format now with high traffic sites. I interpret those figures as a NEED to support WebP export rather sooner than later. The context of that 3% tells a very different story in my opinion. And it is not only a useful format for the web: game engines support this format now as well. It is an effective and flexible image file format - the only one that supports a superset of all the other graphic file formats: both lossy and non-lossy, full alpha, animation, EXIF/ICC Profile/XMP support,... Nope, everything indicates that the use of webp will only grow and grow. It is very, very dumb on the part of the Serif devs to keep ignoring webp. I mean, they are behind: animated PNG and WebP support is growing, and Affinity can't even export a static WebP file.
  14. ? Photoshop never did and still does not support the APNG format (at least, not without a plugin). In any case, for those who wish to convert their animations to APNG or Animated WebP files, download the latest Krita 5 beta and FFmpeg. Krita 5 exports directly to APNG and animated WebP via FFmpeg. And it is free & open source.
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.