Re: [libreoffice-documentation] LO 7.2 Writer Guide macOS edition
Hello Team After giving it some thought about macOS users (me being one), following is a couple of ideas. 1. Printing — add in the macOS print dialog pages to each user guide and explain the options available. I will put together a draft for this after I have finished the Draw Guide this week. 2. Keyboard Shortcuts — rename Appendix A to windows & Linux Keyboard Shortcuts. Create a new Appendix B for macOS Keyboard Shortcuts. Any thought would be welcome. Peter Schofield psaut...@gmail.com Technical Writer, LO Documentation Team > On 2 Jan 2022, at 19:27, Martin Srebotnjak wrote: > > Jean et.. al., > > I took a look at the complete pdf and it looks good. As a macOS user I > would prefer this guide than the Linux/Windows-oriented "generic" guide ... > > I do see where Jean is trying to help the user (which is what documentation > is about) - macOS users are a bit left out by using guides where there is a > small note on the bottom of page 3 and then the keys not marked on their > keyboard are mentioned more than 100 times throughout the book. That is > very user-unfriendly. Now, geeks know about these keys and might not even > need such a basic, GS guide. But we are talking about users needing these > guides - i.e. not familiar with the concept of an office suite, editing > documents, creating slides, adding formulas to sheets, printing ... > > I also see what the others replied - but I do not see this as a problem for > the documentation project - this is a special guide, it can be published > alongside the main guides (and if there will not be time and will for new > ones - the will just not be there). So we could simply add a section to the > documentation site where this could be published. It would not mess with > the line of "official", "generic" guides, yet it would serve a specific > public. "Special guides", "Dedicated guides", "Guide incubator", etc. > > From the download numbers and the publishing orders one would be able to > assess if such guides make sense in the long run for the documentation team > and if they can be made more automatically from the "generic" guides. > > Another possibility would be to add a specific appendix for macOS users > about printing to all the GS guides. Others have mentioned in this thread > that this is the real difference between the OS', yet no one proposed any > solution to this gap in usability of the guides - don't the macOS users > deserve proper printing instructions in the GS guides? > > To sum it up: can't we support Jean's effort, make a difference with the > "regular" guides in presenting it to the public and base our decision on > the success of the guide? > > Ilmari, could you please elaborate: what do you intend to patch regarding > the help build? > > Happy 2022, > Martin > > > V V ned., 2. jan. 2022 ob 13:18 je oseba Ilmari Lauhakangas < > ilmari.lauhakan...@libreoffice.org> napisala: > >> On 2.1.2022 13.44, Olivier Hallot wrote: >>> Em 02/01/2022 06:38, flywire escreveu: On Sun, Jan 2, 2022 at 1:09 PM Jean Weber wrote: > ... Would the team like to have this book as part of the documentation > set? I am unlikely to update it very often, and I am unlikely to > produce a macOS edition of any other books except possibly the Getting > Started Guide - if I have time. > There should be a better way to meet the needs of mac users than a macOS edition in https://documentation.libreoffice.org/en/english-documentation/. Other applications manage to produce one set of docs for different OSs, even if linux screenshots look a bit strange to say Windows users. It will leave mac users with a general feeling of discontent there are no current guides for their application/language. I suggest it should be independent of current guides and the documents should be reviewed in >> the context of better meeting macOS needs. The whole guide preparation process is pretty impressive. Maybe OS-specific keys and screenshots could be scripted in future guides for custom editions but I doubt it is justified. >>> >>> If we add a control variable that hides or show sections/paragraphs >>> depending on the OS, documents will go into a very complex and fragile >>> management scheme where mistakes (e.g. deletion of a controlled >>> paragraph) are easily introduced and unnoticed. Debugging a long >>> document like our guides will be unpleasant at best. >>> >>> Technically speaking, LibreOffice has all tools for document management >>> (version control, fields, track-changes...) but our team must get used >>> to and it is also a entry barrier for newcomers. >>> >>> The Help has a control scheme (, ) for macOS where >>> Ctrl key is changed to Command key and the menu "Tools-Option" is >>> changed to "LibreOffice - Preferences". Those are 99.99% of all >>> differences in Help between OS versions. >> >> In the future I will try a Help bu
Re: [libreoffice-documentation] LO 7.2 Writer Guide macOS edition
I think these are both good ideas, in particular the addition of the printing info for macOS. I doubt most users are reading the documentation like a novel, beginning to end, so having a note in the preface and even an appendix covering macOS shortcuts still might not help the user who looks up a specific task they need to do, and gets confused by the keyboard shortcuts in the chapter they're looking at. For that user, a separate guide for macOS solves the problem, but I agree with the previous comments about the degree of work needed to maintain separate OS guides, and the potential fragility introduced. Would it be too messy to have a brief statement at the start of each chapter reminding the reader to reference the shortcuts specific to their OS in the appropriate appendix? Rachel On 2022-01-04 03:56, Peter Schofield wrote: Hello Team After giving it some thought about macOS users (me being one), following is a couple of ideas. 1. Printing — add in the macOS print dialog pages to each user guide and explain the options available. I will put together a draft for this after I have finished the Draw Guide this week. 2. Keyboard Shortcuts — rename Appendix A to windows & Linux Keyboard Shortcuts. Create a new Appendix B for macOS Keyboard Shortcuts. Any thought would be welcome. Peter Schofield psaut...@gmail.com Technical Writer, LO Documentation Team On 2 Jan 2022, at 19:27, Martin Srebotnjak wrote: Jean et.. al., I took a look at the complete pdf and it looks good. As a macOS user I would prefer this guide than the Linux/Windows-oriented "generic" guide ... I do see where Jean is trying to help the user (which is what documentation is about) - macOS users are a bit left out by using guides where there is a small note on the bottom of page 3 and then the keys not marked on their keyboard are mentioned more than 100 times throughout the book. That is very user-unfriendly. Now, geeks know about these keys and might not even need such a basic, GS guide. But we are talking about users needing these guides - i.e. not familiar with the concept of an office suite, editing documents, creating slides, adding formulas to sheets, printing ... I also see what the others replied - but I do not see this as a problem for the documentation project - this is a special guide, it can be published alongside the main guides (and if there will not be time and will for new ones - the will just not be there). So we could simply add a section to the documentation site where this could be published. It would not mess with the line of "official", "generic" guides, yet it would serve a specific public. "Special guides", "Dedicated guides", "Guide incubator", etc. From the download numbers and the publishing orders one would be able to assess if such guides make sense in the long run for the documentation team and if they can be made more automatically from the "generic" guides. Another possibility would be to add a specific appendix for macOS users about printing to all the GS guides. Others have mentioned in this thread that this is the real difference between the OS', yet no one proposed any solution to this gap in usability of the guides - don't the macOS users deserve proper printing instructions in the GS guides? To sum it up: can't we support Jean's effort, make a difference with the "regular" guides in presenting it to the public and base our decision on the success of the guide? Ilmari, could you please elaborate: what do you intend to patch regarding the help build? Happy 2022, Martin V V ned., 2. jan. 2022 ob 13:18 je oseba Ilmari Lauhakangas < ilmari.lauhakan...@libreoffice.org> napisala: On 2.1.2022 13.44, Olivier Hallot wrote: Em 02/01/2022 06:38, flywire escreveu: On Sun, Jan 2, 2022 at 1:09 PM Jean Weber wrote: ... Would the team like to have this book as part of the documentation set? I am unlikely to update it very often, and I am unlikely to produce a macOS edition of any other books except possibly the Getting Started Guide - if I have time. There should be a better way to meet the needs of mac users than a macOS edition in https://documentation.libreoffice.org/en/english-documentation/. Other applications manage to produce one set of docs for different OSs, even if linux screenshots look a bit strange to say Windows users. It will leave mac users with a general feeling of discontent there are no current guides for their application/language. I suggest it should be independent of current guides and the documents should be reviewed in the context of better meeting macOS needs. The whole guide preparation process is pretty impressive. Maybe OS-specific keys and screenshots could be scripted in future guides for custom editions but I doubt it is justified. If we add a control variable that hides or show sections/paragraphs depending on the OS, documents will go into a very complex and fragile management scheme where mistake
[libreoffice-documentation] 7.3 Base Guide; updated Chapter 1 (Introducing Base) ready for review
Hello everybody, I have produced an updated version of the above chapter and it is ready for review (in Nextcloud). Dev has kindly volunteered to perform the Documentation Team's first review. The chapter has changed significantly since the previous version (see below). It would be very much appreciated if one of our Base experts could skim through the revised chapter just to check that I haven't introduced any errors into the text descriptions of what Base does. (I'm not sure a Base expert needs to read through all the user interface interactions - any problems there should be picked up during the Documentation Team's normal review cycles). Reasons why the chapter has changed significantly include (but may not be limited to): 1. I felt that we should provide a more coherent introduction for novice users, consistent with the guides for other LO components. In particular, answering some of the general queries about Base that I was initially unsure about and providing a brief overview of Base's user interface. 2. I didn't like some of the overly negative points about Base; surely their inclusion as previously worded wasn't a great marketing strategy. These have been toned down without hiding any specific problems that might be encountered. 3. There was a need to anglicize the text and figures and correct some of the confusions that may have arisen during the translation from German to English at an earlier issue. 4. Captions were needed for the many figures that previously had none. (All figures have been replaced with a consistent set captured on my Windows PC). Please also note: (a) The changes were not automatically tracked by Writer - there were far too many changes for this to be worthwhile or manageable. (b) So far I have made no effort to minimize wasted white space by moving figures around. In my opinion, this would be nugatory effort and should be carried out later in the publication process. Regards, Steve -- To unsubscribe e-mail to: documentation+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/documentation/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-documentation] 7.3 Base Guide; updated Chapter 1 (Introducing Base) ready for review
1. What is the proper process for making general comments once someone has commenced a rewrite or review? I'm used to a spreadsheet issue report: number, issue, who, when, status. 2. The Getting Started Guide base chapter and the Base Guide should have a closer relationship. Can the same document serve for GS Guide base chapter and Base Guide Chapter 1 Introducing Base? 3. Definitions must be consistent, especially for Base (GS Guide defines a database but not Base). 4. It's not good enough to assume connecting to other data sources implies you can create it first then connect (UI could be tweaked too): 1. *Database creation*. New HSQLDB databases can be created using an embedded database engine. 2. C*onnection to other data sources*. Databases can be created in, or used from, many widely employed database engines and other data sources, including spreadsheets, text documents, and address books, and these can be connected to Base. 5. *Macros*. LibreOffice Basic and Python macros can be used to simplify running repetitive tasks preventing input errors, increase functionality, and improve form usability. 6. Base can also operate in a standalone mode with an embedded Java-based HSQLDB (HyperSQL DataBase, version 1.8.0) relational database engine in a standard LibreOffice distribution instead of communicating with an external database engine. -- To unsubscribe e-mail to: documentation+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/documentation/ Privacy Policy: https://www.documentfoundation.org/privacy
Re: [libreoffice-documentation] 7.3 Base Guide; updated Chapter 1 (Introducing Base) ready for review
Thanks Martin. Of course, I'm following https://wiki.documentfoundation.org/Documentation which has a fair amount of "(update in progress)". 1. So do need to request approval from the Main Editor to join or do I just add myself to the list for the doc/version? 2. I've used Google Docs before with concurrent users editing documents without any real problems. Do I have to wait for a current rewrite/review to be complete before I can propose changes? On Wed, Jan 5, 2022 at 10:54 AM Martin Srebotnjak wrote: > ...the proper process is to become a reviewer, to check out the chapter, > announce it on this list and write that down into the guide status document > (so that there are not conflicts of concurrent reviewing) and review the > file either by entering changes as tracked changes (if it is about typos or > not clear wording etc.) or adding comments to the text with remarks, > proposals for change etc. And checking it back in and announcing on the > list the chapter has returned... > -- To unsubscribe e-mail to: documentation+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/documentation/ Privacy Policy: https://www.documentfoundation.org/privacy
