Michael Lloyd

Please honor the standard Windows hotkey convention, and your Windows users, and incorporate the following: CTRL + F4 as Close Window SHIFT + DELETE as Cut CTRL + INSERT as Copy SHIFT + INSERT as Paste I understand users can configure hotkeys, though many Windows users expect some or all of these hotkey sequence to work as expected. Further most users will 'fight with'/'bend to' application defaults rather than configure such application behavior details. These refinements will improve application usability and user efficiency. I also understand CTRL + W is defined as close window (is this a Mac convention? I have not seen this behavior in other Windows applications.). Retaining CTRL + W, and adding CTRL + F4 or replacing CTRL + W with CTRL + F4 are equally welcome refinements. I have not tested for the possibility in Affinity Publisher to allow for user configured multiple hotkey sequences for the same function (e.g. CTRL + X and SHIFT + DELETE both as cut). It is common for Windows users to be familiar with and use both, or prefer one over the other. Please consider incorporating this behavior in the Windows versions of Affinity Designer and Photo. Thank you for considering.

To learn applications I sometimes create a shortcut to the online documentation within my Windows Start menu. While setting this up I noticed an inconsistency within Serif Affinity applications. All Affinity applications have an 'index.html' file in the same location (Affinity Publisher slightly different, as the directory reference is Beta specific). The inconsistency I discovered is that running the 'index.html' file for Designer and Photo runs the integrated help in the default web browser. When running Affinity Publisher 'index.html' file presents a web error message 'file not found'. What this tells me is that there are inconsistencies in conventions used in developing the applications. Inevitable divergence in thinking and approach happens as development groups focus on solving problems, and implementing improvements for a particular application without deep and consistent consideration for handling similar issues across a brand. My suggestion: A Serif team (representatives from Affinity development groups) meet on a consistent schedule to discuss differences in conventions used between Affinity applications and determine consistent conventions in application behavior, development approach, directory structures, terminology, UI, etc. to ensure consistent development, documentation and user experience between Serif Affinity applications. This team would also be responsible for reviewing application improvements to identify implementation concerns with other applications, leverage efforts, and help determine best approach across applications. This effort should provide the following benefits: Help ensure development approach is consistent and therefore ideal between applications Code maintenance is simplified Improved user experience and consistent interface interaction between applications and platforms Increase Serif Affinity application perception as a polished and professional brand Speed overall fixes and improvements across all applications by proactively sharing and leveraging efforts Thank you for considering my suggestion.

Free Windows Explorer codecs to enhance graphic design related file management. SVG codec / viewer for Windows Explorer. Supports 32-bit and 64-bit, Windows 7, 8 and 10. SVG Explorer Extension - Download SVG Viewer Extension for Windows Explorer v0.1.1 https://svgextension.codeplex.com/releases/view/118790 SVG file management enhancement. Adobe developed, ISO proposed, open source format for camera RAW file standard. DNG codec / viewer for Windows Explorer. Supports 32-bit and 64-bit, Windows 7, 8 and 10. Adobe DNG Codec 2.0 http://www.free-codecs.com/adobe_dng_codec_download.htm DNG camera RAW file management enhancement. I hope these facilities enhance your productivity and workflow.

I am an American living in Southern California and my wife is from China. We send packages to China periodically. I too have had many reliability issues delivering to China. This is an internal problem in that country. I have learned Federal Express can deliver to China reliably. Since using them I haven't experienced a single problem getting a package to it's destination. Federal Express does not depend on Chinese services for final delivery as is the case with other delivery services. Federal Express may also prove useful for delivering to other, more difficult-to-deliver-to countries. ~ Hope this helps.

Ok Serif / Affinity guys... This is driving me crazy! Previously I have submitted this suggestion, though I don't believe I was heard. IMO Affinity products desperately need the ability to auto-hide panels. See [https://forum.affinity.serif.com/index.php?/topic/31218-multi-uiux-suggestion-auto-hide-panels/] I am using a very large notebook computer with a 17" screen. Large screen for a notebook, though smaller screen size for graphic design work. With this monitor using the panel controls in Affinity products is frustrating. There simply isn't enough room! I group panels needing more vertical space (layers, effects, history, brushes, etc.) together. Panels needing less vertical space are also grouped. Regardless how it is organized I do not have enough vertical space to effectively use the panels. Some of the panels require large vertical space, some medium, some smaller. With 3 stacked sets of panels the larger panels are way too cramped. Even if I group the medium and smaller panels together (which puts way too many panels in the smaller panel group), there still isn't enough vertical space for the larger panels. With smaller monitors, having panels on both sides of the screen (without auto-hide) is obviously impractical. Working with cramped panels is extremely clumsy and frustrating. Affinity UI panel design is not elegant for smaller monitors!!! If I could auto-hide panels (as was implemented in Serif *Plus applications), I could put panels on both sides of my monitor and have all the panels I find useful easily accessible. Current implementation forces users with 'smaller' monitors to make significant concessions in their use of panels. Regardless of screen size, the ability to auto-hide panel groups would be useful for all/most users, as this would allow users to better organize their application interface, and enable users to have more panels immediately accessible. This would make the use of panels in Affinity applications significantly more elegant. PLEASE consider implementing an auto-hide feature in panel groups in Affinity applications.

William, I couldn't agree more. I didn't realize the file was closed when using File/Edit in Photo... in Designer. I understand this functionality demonstrates the strength and unusual capability of Affinity products being able to seamlessly open and modify files from other Affinity products. This capability could be useful, however this functionality is not normally the desired behavior. Perhaps the File menu option should remain as it is, possibly with Designer/Publisher being closed rather then leaving Designer/Publisher open with no files open. Upon further testing I better understand what is happening. I realize the current functionality looks similar, though was designed with a different purpose in mind. I respectfully, and completely disagree. Though the current implementation could be useful, the primary desired behavior is to be able to select a/an image(s) within Designer/Publisher, open the image(s) within Photo for modification, and close Photo with the modified image(s) transferred back into Designer/Publisher for further work on the parent document. [Feature implementation may require only 1 image could be transferred to Photo for editing.] The purpose and use of the above described behavior is significantly different from what is currently implemented and should be considered as a new feature enhancement.

I have since found the feature under the File menu. However I still believe it should be available as a context menu option (i.e. right mouse button menu on the object), as this more object oriented implementation will make using Affinity Photo from within Affinity Designer/Publisher (and vice versa) more intuitive, faster to use and easier to find.

PLEASE provide 64-bit scanner support for Windows Affinity applications. Full suggestion here: https://forum.affinity.serif.com/index.php?/topic/33677-windows-affinity-designer-and-photo-scanning-support/

PLEASE provide a Mac and Windows PDF manual. I don't care about printing, but using it on a phone or 2nd screen is very useful. Also, as mentioned earlier ePub (on phone apps) and PDF conversions do not provide all information, which makes those options insufficient. This is very important to me. Isn't PagePlus X9 among the best applications available for PDF manual creation?

Affinity Designer and Photo for Windows do not currently include the ability to scan documents within applications. I understand scanning is an issue with Affinity Designer and Photo under Windows, as some scanner manufacturers only provide 32-bit, not 64-bit driver support. https://forum.affinity.serif.com/index.php?/topic/32310-aquiring-photos-from-scanners/?p=156987 However, some scanner manufacturers do provide 64-bit scanner drivers. Until there is a solution within Affinity products to provide 32-bit scanner driver support (if such a solution will be developed)... PLEASE provide 64-bit scanner support. For several years now Windows operating systems have been primarily 64-bit, as 32-bit operating systems cannot address more than between 3.5Gb to 4Gb of RAM. Most systems (especially systems for graphic design and similar) come pre-installed with more then 4 Gb RAM, requiring a 64-bit OS. Though some/many scanner manufacturers are not keeping up with the need for 64-bit scanner drivers, the need is firmly established, and will only grow, and become a hard requirement for those purchasing scanners. If only 64-bit scanner driver support is incorporated into Affinity Designer and Photo, that would provide Affinity software users the ability to scan within the applications, with provided 64-bit drivers. With newer scanners, users have a strong argument for scanner manufacturers to provide 64-bit drivers. With new scanners, users can return their scanner in favor of scanners providing the needed 64-bit drivers. The problem is: Microsoft Windows does not include the ability to use both 32-bit and 64-bit drivers for both 32-bit and 64-bit applications (i.e. a level of abstraction in the scanner subsystem); All scanner manufacturers are not providing 64-bit Windows drivers; Affinity Windows applications do not provide any scanner driver support. Supporting 64-bit scanner drivers for Windows Affinity applications provides a solution for Affinity application users and shifts the problem/blame to Microsoft and scanner manufacturers.

Yes... 'Exactly the same length of time'... Actually Windows users have been waiting longer. Windows users familiar with development-related statements (myself included) knew very early that Affinity products were being developed for both platforms, not from the 'announcement in 2016'. The 2016 'announcement' was a commercial for the masses unfamiliar with common publicly available information. Serif planned to release Affinity products, first for Mac, then for Windows from conception, not later in the development cycle. From the earliest Affinity days there are Serif statements explaining this. The Affinity product line has been designed around key approaches and philosophies... Common file format, cross application and platform (OS) functionality and compatibility, application core being exactly same between platforms (i.e. layer model in application design architecture), released first on Mac then on Windows, and more. It wasn't that the Mac Affinity products took 5 to 6 years to develop, where the Windows Affinity products took 1 year. They were developed from the same core code base, with interface and OS layers developed for the specific operating systems. Windows Affinity applications were not an after thought or 'now that we know Mac people like this, lets make a Windows version to see if Windows guys like it too' nonsense. Key to success of the Affinity product line and as a viable adoption choice for many designers and related organizations & departments is to have the products available on both Mac and Windows, and be cross compatible. Serif knew this from conception, and explained it upon earliest Serif Affinity public announcements.

It did sound like the help file... For clarification users need a PDF or epub version of the manual (readable on Mac, Windows, phones and tablets. The integrated application help file is useful for reference, but as a manual to be read through and studied, this format is clumsy and inadequate. Many posts represent this sentiment.

Breaking up forum sections is essential for usability and inevitable. The primary code base for Mac and Windows applications is identical, therefore application capability and features are identical. Therefore much of the forum should not be separated by OS, as this would orphan valuable content from users of the OS where not posted. However OS specific sections are needed. Though there are several sections listed below this will help keep valuable material from being quickly pushed several pages down the list. Over time these forum sections will explode with content. I believe the suggested forum sections and similar labeling will serve to keep the forum manageable and separate content in a meaningful and useful manner, with minimal redundancy and confusion. Suggested Forum Sections: News and Information Support - Affinity Designer Support - Affinity Photo Support - Affinity Publisher [Each of the above should have an FAQ thread administered by Serif.] Support - Applies to Multiple Applications [Needed?] Support - Affinity Mac OS Related Support - Affinity Windows OS Related [The above 2 sections may benefit from an FAQ thread administered by Serif.] Tools and Resources - All Affinity Applications Training - Affinity Designer Training - Affinity Photo Training - Affinity Publisher Training - Applies to Multiple Applications [As needed] Training - Affinity Mac Specific [As needed] Training - Affinity Windows Specific [As needed] [The last 2 (above - OS Specific) might be implemented as a thread in each previous section, as needed.] [include 2 (pinned) Tips and Tricks threads in each section - One administrated by Serif the other by users.] [serif provided training would be more organized and inviting if implemented as web pages.] [users should be able to submit Affinity training material and links not created by Serif.] Share your work - Affinity Designer Share your work - Affinity Photo Share your work - Affinity Publisher Suggestions - Affinity Designer Suggestions - Affinity Photo Suggestions - Affinity Publisher Suggestions - Applies to Multiple Applications Suggestions - Affinity Mac OS Related Suggestions - Affinity Windows OS Related Bugs - Affinity Designer Bugs - Affinity Photo Bugs - Affinity Publisher Bugs - Applies to Multiple Applications Bugs - Affinity Mac OS Related Bugs - Affinity Windows OS Related

Thank you for the explanation. Good points! Often legacy technology has benefits and advantages over looked by many. Besides the size problems with CRTs they also give off radiation in addition to visible light that can be hard/damaging on eyes. However the color benefits mentioned above are significant. I find myself designing elements, printing them, then adjusting colors as needed.

When working with photos/images in Affinity Designer, (with Affinity Photo installed), there should be an easy way to launch Affinity Photo (or another chosen bitmap editor) from within Affinity Designer to edit bitmap images (beyond the photo editing capability integrated into Affinity Designer). This should be available both from the right mouse context menu and the context aware bar across the top when a bitmap image is selected. With such excellent Affinity application interoperability I am surprised this has not yet been implemented. This type of integration should also be incorporated into Affinity Publisher. Another possible interface enhancement, could be to (optionally - in preferences?) replace the Affinity Designer Pixel Persona with the Affinity Photo 'Photo Persona'. If this capability were implemented, it would still be useful to include the ability to launch Affinity Photo as a bitmap editor from within Affinity Designer, as Affinity Photo provides further capability (i.e. Liquify Persona and Tone Mapping Persona). I would love the integration of the Affinity Photo 'Photo Persona' with Affinity Designer when editing bitmap images within Affinity Designer. (Considering how these applications are designed I wouldn't be shocked if such integration were technically feasible.)