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

Peter Breis

Members
  • Posts

    20
  • Joined

  • Last visited

Reputation Activity

  1. Like
    Peter Breis got a reaction from Newstech in Affinity Designer 2 User Guide   
    I guess I am older than you ūüėä.
    I can remember when Apps had manuals and how useful that was. Both to the developer and the User
  2. Like
    Peter Breis got a reaction from Newstech in Affinity Designer 2 User Guide   
    It is not necessary to know what anyone's specific needs are to write a good manual.
    Simply provide a logical order, breakdown and an index.
    It is much faster and more systematic to scan through a book (which allows notes to be added) than videos or online Help files.
    It also is a good check for software publishers to write manuals, it helps resolve UI/UX issues and is a way of testing just how easy it is to understand and use an App. Particularly in the case of Publisher which is a DTP App to create manuals and other documents.
    I'm surprised the software development team does not create a manual in parallel with the software development, as it tracks what has been done and what needs to be added. The problem is developers find it hard to put themselves in the place of Users and find it a chore to explain themselves.
  3. Like
    Peter Breis got a reaction from Jawbones in Affinity Designer 2 User Guide   
    I guess I am older than you ūüėä.
    I can remember when Apps had manuals and how useful that was. Both to the developer and the User
  4. Like
    Peter Breis got a reaction from Jawbones in Affinity Designer 2 User Guide   
    It is not necessary to know what anyone's specific needs are to write a good manual.
    Simply provide a logical order, breakdown and an index.
    It is much faster and more systematic to scan through a book (which allows notes to be added) than videos or online Help files.
    It also is a good check for software publishers to write manuals, it helps resolve UI/UX issues and is a way of testing just how easy it is to understand and use an App. Particularly in the case of Publisher which is a DTP App to create manuals and other documents.
    I'm surprised the software development team does not create a manual in parallel with the software development, as it tracks what has been done and what needs to be added. The problem is developers find it hard to put themselves in the place of Users and find it a chore to explain themselves.
  5. Like
    Peter Breis reacted to R C-R in Affinity Designer 2 User Guide   
    I have no idea what you mean by that but if you are referring to the price of Macs, a lot of people think they are neither overpriced for what they offer nor have anywhere as many OS software problems as Windows.
    Of course, YMMV.
  6. Thanks
    Peter Breis got a reaction from Oufti in Adding months to calendar pages.   
    Here is an example of a table used for creating a Calendar month. The big cells are created by selecting a bunch of smaller cells and merging them. The lines, if you want them are made by selecting certain cells and giving them a border:

    The dates for particular months you can quickly copy and paste from a single table set up like this, deleting the dates you do not want for shorter months:

    I created these in Pages for Mac because it is quicker and cleaner to show you, but the same applies to Affinity Publisher or any capable layout App.
    Affinity Publisher is some what cruder and clumsier but allows you to create commercially printable files.
    I am sorry it took a bit longer to post this response, but Affinity has a max 5 posts per day limit for some reason.
  7. Confused
    Peter Breis got a reaction from Westerw√§lder in Affinity Designer 2 User Guide   
    Understood, but macOS has a Library that does all the hard yards of finding and linking to menu items in Apps etc, that it appears Serif did not use.
    I am well aware of the Affinity documentation and videos and have them all downloaded and will go through them.
    I am also aware that many people like using YouTube videos to learn new subjects, I use them myself, but for in-depth learning of software nothing beats or is faster to consult well written documentation in book form that you can correct and annotate.
  8. Confused
    Peter Breis got a reaction from Westerw√§lder in Affinity Designer 2 User Guide   
    It is not a Sonoma bug, as I said other Apps search works, this is specific to Affinity.
    On-line search works because it is using browser engine not Apple's Help library.
    I appreciate there might be work arounds, which I will use, but it is a distraction from getting things done.
    Reminds me of working in Linux. Spending more time searching bug/UI/UX glitches than on work. ūü§∑ūüŹĽ‚Äć‚ôāÔłŹ
    I can do all of this much, much faster in Pages, just thought I'd have a try with the latest version 2.2 of the Affinity Apps to see if they are useful. I also have the Adobe Apps.
    If I can overcome the problems with the Affinity Apps, I might use them on my PCs where I do not have Apple's creative/productivity Apps.
    Was also going to experiment with MsOffice and the Google Apps.
    ____________________________________________________
    How do I set up my sig. I have been hunting for where to do that but can't find it.
  9. Haha
    Peter Breis got a reaction from Westerw√§lder in Affinity Designer 2 User Guide   
    I guess I am older than you ūüėä.
    I can remember when Apps had manuals and how useful that was. Both to the developer and the User
  10. Like
    Peter Breis got a reaction from deeds in Why I like reading software manuals in .PDF form:   
    AllanP
    Apple still creates User Guides for its iWorks suite and certain hardware, also there are Teacher Creativity guides. All available in their Books App.
    But it is very much a "used-to" thing. A real shame. Nobody feels they have to give a stuff so it's sunk to the lowest common denominator.
  11. Like
    Peter Breis got a reaction from deeds in Why I like reading software manuals in .PDF form:   
    You are lucky you got that screenshot.
    Who except nerds like me constantly documents their searches on the off chance that someone will ask for "more in formation" ūüėä
    Yes it is possible in that instance I got V1 Help despite my search, I took a snap so I'd have the topics list for when I created my own manual to try and sort out how Publisher works. Something which as I've said, would be better if Serif did it. I'd put my hand up for the job, but can't fix everyone's shortcomings, I've got work of my own to do.
  12. Like
    Peter Breis got a reaction from deeds in Why I like reading software manuals in .PDF form:   
    It is a pity I did not have a time machine to go into the future.
    And that was an odd but tartly incorrect correction of my grammar.
  13. Like
    Peter Breis got a reaction from deeds in Why I like reading software manuals in .PDF form:   
    I agree with all the sentiments expressed above and a huge thank you to Mike for creating the Publisher 2 pdf manual, something Serif should have done.
    My only regret is that I discovered this after I spent an entire day saving The Publisher Help pages to pdf with the intention of creating a manual myself.
    btw In doing this I found Serif has two sets of Help files. One reached through the Help menu in Publisher 2 and the other via the Support pages on this website, and they do not match.
  14. Like
    Peter Breis got a reaction from jmwellborn in Affinity Designer 2 User Guide   
    I reported to Affinity Support that Search fails in Help on the Mac. They are aware of the bug. But not much "Help" ūü§∑ meanwhile.
    The Help pages lack key details that make it hard to follow.
    I was trying to format/size cells in Tables the exact details that the Table pallet was hiding from me with no indication that there were more fields below if I only pulled down the window.
    When I write a manual I show the full path from the App menu down to the exact location of the Input wherever that may be.
  15. Like
    Peter Breis got a reaction from jmwellborn in Affinity Designer 2 User Guide   
    I guess I am older than you ūüėä.
    I can remember when Apps had manuals and how useful that was. Both to the developer and the User
  16. Like
    Peter Breis got a reaction from jmwellborn in Affinity Designer 2 User Guide   
    It is not necessary to know what anyone's specific needs are to write a good manual.
    Simply provide a logical order, breakdown and an index.
    It is much faster and more systematic to scan through a book (which allows notes to be added) than videos or online Help files.
    It also is a good check for software publishers to write manuals, it helps resolve UI/UX issues and is a way of testing just how easy it is to understand and use an App. Particularly in the case of Publisher which is a DTP App to create manuals and other documents.
    I'm surprised the software development team does not create a manual in parallel with the software development, as it tracks what has been done and what needs to be added. The problem is developers find it hard to put themselves in the place of Users and find it a chore to explain themselves.
  17. Like
    Peter Breis reacted to MikeTO in Why I like reading software manuals in .PDF form:   
    You're most welcome. Keep an eye out for the next version when 2.3 is released. It's going to cover a lot more. It also covers a lot of the options that aren't explained in depth in the help system.
    FYI, the help files should be identical. I've compared the help files before and found no differences, except in the beta of course. Perhaps you were looking at the v1 help files online? You can find all versions here: https://affinity.help
  18. Like
    Peter Breis reacted to meyer.wil in Why I like reading software manuals in .PDF form:   
    My comment was not specific to Serif, nor to Affinity help files, but to the challenges in assembling non-linear help files. A technical book is a major undertaking, but easier to manage than help files. Easier, at least, to assess coverage. There are good, common sense approaches to attempting to manage coverage in help, but those I have seen are simply disciplines, and depend on the use of separate tools, usually search tools, for their success.
    I will continue to assert that the quality of documentation has deteriorated in the industry at large, since printed manuals ceased to be produced. Most help files are designed for reference use, not for learning. To that degree, Affinity help is better than many I have seen.
  19. Like
    Peter Breis reacted to MikeTO in Why I like reading software manuals in .PDF form:   
    When you write online help you have to keep it shorter for viewing inside the online help viewer, even if you provide a web version of it as Serif and Adobe do. Serif has also wisely chosen to bundle the online help with the applications rather than requiring internet access - Adobe requires internet access unless you choose to manually download the help files. But including them means you have to use very few screenshots to keep the total package small because screenshots must be localized to each of the eight languages that Serif supports and there aren't separate installers for each language.
    Managing the online help for Affinity would be a difficult task because there are so many overlapping features in the three applications. if you make a change to character formatting, you have to change the help page for the three apps multiplied by eight languages for a total of 24 pages. And that's if it's only mentioned on one page. If it's mentioned on three pages then that would be 72 pages to update. It's so much easier to write a manual for a single app in a single language. I can add as many examples and screenshots as I like.
    After spending more time in Publisher's help file than probably most users, the main recommendation I'd have for improvement is to eliminate the pages that aren't part of the primary navigation system. Some pages are in the left nav, others are not, so you're never really sure if you've read everything about a topic. The reason for these pages to be omitted from the navigation is so that they can be referred to from more than one place, but as you said it makes it non-linear. If everything was in the nav then you could read through the Publishing and Sharing section from start to finish and know that you'd read it all. This would be a big change so it's not something that could be done easily.
  20. Like
    Peter Breis reacted to meyer.wil in Why I like reading software manuals in .PDF form:   
    It is a sad reality, too, that the non-linear composition of help files all but guarantees skimpy exposition and poor coverage. 
  21. Like
    Peter Breis reacted to deeds in Why I like reading software manuals in .PDF form:   
    100% Agreed!
    There's another (implicit) benefit of PDF Manuals... providing one forces the software maker to think about and articulate their product's features in a linear and complete manner. This, quite surely, benefits everyone; including the software maker, as it will more easily reveal workflow problems and excess user interactions for any and all operations.
  22. Like
    Peter Breis reacted to Grant Robertson in Why I like reading software manuals in .PDF form:   
    When a manual is in .PDF form, I can simply read one page after another, till I get to the end, and know I have read the entire manual. HTML-based manuals force me to navigate a maze of links, hoping beyond hope that I have successfully found every page. Even with a navigation bar on the side, one cannot be sure that every single page is linked to in said navigation bar. Many, many HTML-based manuals end up with sub-pages that can only be found via an obscure link, buried in a paragraph somewhere. So, you are forced to click every link you see, out of fear of missing out. This makes reading a manual kind of exhausting. In a .PDF, I can annotate the document as I see fit. I can highlight important parts. I can insert any questions I may have while reading (even when away from my main computer). Then, I can go back and try to answer those questions when I am either at my main computer or when I am online. Plus, sometimes you just want to insert a question and then keep reading. With HTML-based help, you have to use a separate method to keep track of all these notes and questions. It then becomes extra tedious to keep track of which note or question is about which part of the manual.  I can synchronize a .PDF manual (along with all those annotations) between different devices, simply by storing it in some cloud-based service. Yes, I can sometimes save "favorites" or "bookmarks" in an HTML-based help system, but those can never be synchronized between all my devices. So, if I want to make use of that feature, I am forced to always read said help on a single device. Without these abilities, reading HTML-based help can become extremely frustrating. Especially when said "help" glosses over most of the actual detail of how to use the program. As a former network manager, and a former technical writer, with a degree in Computer Science and Education, I can definitely tell the difference between me simply not being able to understand something and just poor documentation.
     
    I do have the tools available to convert existing HTML-based manuals to PDF. But it can be a tedious and error prone process. And the whole process must be repeated each time the HTML-based manual is updated. It is always far better to just start from the source files and use a reliable utility to produce the .PDF version of the document. Usually, the same tool that generated the HTML-based manual has a feature to generate a .PDF file as well. So there is often no real excuse for a company to neglect doing this.
    Sometimes it feels as if software companies rely solely on HTML-based documentation just so they never have to worry about users working from an outdated copy of the manual. But I also feel that this is a bit of a cop-out.
  23. Like
    Peter Breis reacted to MikeTO in Unofficial PDF Manual - Expert Guide to Affinity Publisher   
    Updated for Publisher 2.5 (May 2024)
    Publisher Manual May 23 2024.pdf
    This free in-depth manual is filled with steps, tips, and recommendations for:
    Documents, Pages, Master Pages, Sections, and Baseline Grid Character and Paragraph Formatting Text Styles (paragraph and character) Text Frames, Text Flow, and Stories Images and Picture Frames Books and Chapters Cross-References, Table of Contents, and Index Notes - including Footnotes, Sidenotes, and Endnotes Fields - including Page Numbering, Running Headers, and Custom Variables Anchors and Hyperlinks Printing and Exporting Settings New for this edition: Getting Started, Variable Fonts, a Dutch, Polish, and Ukrainian terminology dictionary, and more This manual does not cover other types of objects, path and photo editing, or the other artistic features.
    Q&A
    Is this really free? Yes, it's copyrighted only to prevent others from publishing it as their own Is there a longer manual I can purchase? No Is there a version for Designer or Photo? No, but many of the features are the same so it will still be relevant Is there an iPad version? No, the steps and screenshots are for the macOS and Windows versions Why does it use a print layout if it's a PDF? It's a demonstration of how to use the features it describes to create a print book Previous 2.4 edition:
    Publisher Manual Feb 26 2024.pdf
    You might also like:
    Special Characters Quick Reference Chart: https://forum.affinity.serif.com/index.php?/topic/176386-special-characters-in-affinity-quick-reference-chart/  
×
×
  • 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.