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

Domske

Members
  • Posts

    15
  • Joined

  • Last visited

Everything posted by Domske

  1. TL;DR: - Add update notification button on the toolbar which opens the current update dialog when clicked. - Instead of showing the dialog, make it visible on the new button. Done. Don't get confused with the login button. It has nothing to do with that. I just noticed that for a good position new button as an example. ^^ 1. Update available -> Show update notification button or change its appearance. Don't show the modal. 2. Click on the button -> Show the update modal as it currently is. No further logic required. No braking changed. A sweet little implementation. Honestly, I would do it if I had access to the source code. Anyway, just a suggestion. Let me know if you have any further questions or concerns.
  2. Just a quick and dirty sketch: This can be used for other notifications too. Or use it only for update. I'm sure Serif find a nice solution. Even if you show a small non-blocking bubble message below, it would be better as the current solution. Or flash the icon to attract attention. Let the user know, hey here is an update. But don't annoy the user.
  3. Not really. A notification in background is not the same as a dialog. Maybe you misunderstood me. A dialog/modal is a window that is displayed at the top to prompt the user to take action. A notification is just a message or indicator in the background. For example a bubble which disappears after seconds or only shows an icon/button with a red dot (with or without a number of notifications inside). The user can decide when to take action. This solution does not bother the user. As long as it is not implemented in a disruptive manner. For example, covers important UI and doesn't disappear after certain duration. I could draw something or post references to frontend frameworks to demo what I mean.
  4. That is not the point. I know that I can decline the update dialog. But it's still an additional step and annoying. It's like using alert window in websites. A bad user experience. Not the worst problem ever. But something that can be improved or avoided. I see no reason to stick with current behavior and block any improvement. For the implementation, the idea: Add a new button next to the account button (top right) with a notification or update icon. Only display it if an update is available or change the icon or a red dot for notification to indicate it. Easy.
  5. Yes, I'm on Windows (11) and installed with the setup file. It's annoying when the update dialog is displayed on front of me which blocks the whole program. For example, I start the program with a file to edit. But instead of loading the file the dialog is nagging. I like updates. But in this situation I want the file load and not the modal. To be honest it's not a matter of opinion, it's actually bad UX. A non-blocking notification would be better if an update is not mandatory. You could look at VS Code for inspiration. You get an notification and the update is installed after closing the app. Option for auto download and install or manual.
  6. I'm looking forward to updates. But this blocking modal is just annoying. Instead of this dialog you should simply display a notification. With the option to download the update. Which is then installed when you close the application. The notification should be non-blocking. Show it parallel. The opened document should be loaded. The notification could be a message bubble or just an icon with a counter or red dot. Similar like in Visual Studio Code.
  7. Thanks debraspicher. Yes, that's a point. The preset templates should be very simple. Honestly, I'd rather create my own templates. I like figuring it out and tweaking it perfectly to keep it simple and effective to my needs. On the other hand, this takes a lot of time and I would like to know what best practices apply specifically to this program and how the creators would do it. Find ideas, etc. Like the Samples, the Templates could be optionally downloaded. It's like the formats under the New section. Just with more preset settings, elements and maybe designs. Idk. I just looked at the template tab to create a tri-fold brochure with it's confusing order. ^^ I'm almost done and have ended up creating 1/3 rectangles on two A4 sheets in the order 5-6-1, 2-3-4. So do whatever you want with this suggestion. It's ok if Serif don't want it. Just consider.
  8. I mean official built-in default templates. I know search engines. This is just a feedback, a suggestion to include such basic templates into the program.
  9. It would be great if you include templates like letters, brochure, books and other basic stuff. Currently the templates section is empty. In all programs of the suit (Photo, Designer, Publisher). The samples are interessting but why not adding templates? So that the user can get started quickly. For example creating a brochure in Publisher. A 2x DIN A4 with each 3 sections (trifolds) which each section has its order. It would be great to have such templates. Maybe with different designs.
  10. Hmm, ok Old Bruce. This seems to work better. Thanks. I understand... Ok, it doesn't explain where the float values come from. Since I always worked with integer and snapping option. But anyway... it maybe fixes the problem... Will see next time. I just wish there was a button to iterate and align all element positions and sizes to full pixel. I have a lot of them to fix now. 😓^^ Btw. do the options Force Pixel Alignment and Move By Whole Pixels not conflict? I mean, Force Pixel Alignment should be dominant. Whatever... It resolves my issue by disable Move By Whole Pixels and only tick Force Pixel Alignment. It's ok... 👍
  11. Good hint walt.farrell, thanks. I hope, there will never be a value like 0.0000001. ^^ I wouldn't go higher than 3 decimal places. Another idea: An option to ensure that values are rounded to specific decimal places. So that the actual values are always the same as displayed on UI. Or display an icon (warning icon) what informs that the actual value and displayed values are different. And a click on the icon, fixes it by rounding to the given decimal places. But the integer option I suggested above would be also great.
  12. I extracted the issue from my original project which I was working on for some time. In this example I moved rect on rect with snap and whole pixel option. And at some point it happened that the position or size of an element suddenly shifted by a fraction of a pixel. I suspect that snap or rounding didn't work properly. I cannot reproduce it on a new file. It's like the Heisenberg's indeterminacy principle or demonstration effect. But I've experienced this on several projects where I wanted to perfectly snap to elements. In general it's about primitive shapes like rectangles. And in this particular case I see rounded numbers on the Transform panel (x, y, width, height). Ok, let me explain ... I have some files for you... You can see a darker line between the 2 green rectangles. It's because the background shines through. Both rect have exact 48 x 48 px. And have the position 0, 0 and 48, 0. No fraction visible on Transform panel (right bottom). I always snapped and moved by whole pixel. But at some point the fraction appeared. I didn't see at first glance. I cannot explain. I never moved or snapped the elements other than full pixels. But in general it works great. So I cannot reproduce it on a new file. It just occurs on real projects when working some time on it. When I export the project as SVG, I see a fraction value for width. It's 47.975 not 48 for the first rect. So there is a gap between. Not sure if this only occurs to the size... I attached the afdesign and SVG files in demo.zip. If you click on each rectangle you can see on the Transform panel of Designer that the values are integers 0, 0, 48, 48. No fraction visible. The value on UI is rounded up to 1 decimal places. If you re-enter the value from keyboard, then the values are correct as displayed and the gap disappears. Not sure if this will help. Since it's not clear when this issue occurs. Therefore I would rather suggest to implement or change the feature for working on whole pixels. It must be ensured that all elements are always moving and sizing on whole pixels. Even if an element was on e.g. x 12.3. The x value must be rounded to full pixels like 12 when moved. Same with the size. My unit is in px btw. But regardless of the unit. It means integer values not float. Pixels or centimeters does not matter. I mean "Force Pixel Alignment" and "Move by whole Pixels" should work as I expect. Never allow float/fraction values. Maybe only if you enter the value manually to the Transfrom panel. But if you move or resize the element, it should always have integer values. And in my case, you see the value 48, but behind the scene it's 47.975 or whatever other floating point. I suspect that there was a rounding error while I worked on the project. I cannot say, when this happens. And I cannot prove if this was a user error. But I swear I never moved or resized by fraction values. Always used the snap feature. My proposal: The Pixel options should work as expected. Only integers allows. Or implement another option to only work with integer. Maybe allow float for manual input. But as soon as the user moves the element again, it snaps back to the integer (rounded value). Or for what else are the options "Force Pixel Alignment" and "Move by whole Pixels"? Ok, the Move by whole Pixels is about the movment itself. Means e.g. from x 12.3 to 13.3 and so on. So I think it works as intended. It's ok. And what does "Force Pixel Alignment"? Anyway... it would be great if there is an additional option to snap always to integer values. demo.zip
  13. The snapping feature of Designer does not properly work. Ok, in general it works fine. But you don't see this in most of time. But if you want to work exactly, you will notice that suddenly some elements overlaps or are too small. Just a fraction of a pixel. "Move by whole pixel" does also not work. Sometimes you see values like 48.1 or 47.9 instead of 48. But even if you see 48. It's not exact rounded under the hood. I suspect it's maybe 48.0001 which are rounded on UI but not actual on the element. Which results in slightly sloppy edges. Because either the background shines through or overlaps another element. So you'll see a pixel line on the edge with opacity depending on the rounding error. Long story short: - The "Move by whole pixel" feature should not allow other than integer. Perfect rounded values without fraction. Only 0, 1, 2, 3, 4. Not 0, 0.5, 1.9 or 1.00000001 (behind the scenes). - The snapping feature should fix the rounding error. Check your source code and ensure a rounded value. Maybe cast to interger. I don't know what language you use... - Alternative it would be great if there is a button or menu entry somewhere what fixes all rounding issues of all elements. Just iterate through all elements and points and round it to integer pixel. But don't cut like a cast to interger. Because 2.9 becomes to 2 (should be 3). You can see this issue when exporting pixel image like PNG or enable pixel view mode. Affinity Designer 2.2.1
  14. Please don't annoy the user by displaying a blocking dialog. If this dialog is displayed, the program will not completly load. I have to click one of these tiny buttons to continue. This is very annoying and a really bad UX. I'm happy for every new update. Thanks for this. :) But please inform me in another way. e.g. display a non blocking notification. This should not overlay important buttons / menu.
×
×
  • 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.