Post History
This is all about recognition. The user may recognize the component being mentioned by name (verbal) or by sight (visual). Recognition by name is sufficient in most cases. If you are going for re...
Answer
#4: Attribution notice removed
by
System
·
2020-01-03T20:41:56Z (almost 5 years ago)
Source: https://writers.stackexchange.com/a/32891 License name: CC BY-SA 3.0 License URL: https://creativecommons.org/licenses/by-sa/3.0/
#3: Attribution notice added
by
System
·
2019-12-08T07:48:15Z (almost 5 years ago)
Source: https://writers.stackexchange.com/a/32891 License name: CC BY-SA 3.0 License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision
by
System
·
2019-12-08T07:48:15Z (almost 5 years ago)
This is all about recognition. The user may recognize the component being mentioned by name (verbal) or by sight (visual). Recognition by name is sufficient in most cases. If you are going for recognition by name, the the reason for bolding the text in the manual is to offset the name from the rest of the text so that the reader can easily pick out the name. It is not about making the text look like the text in the interface, because you are relying on recognition by name, not appearance. On the other hand, if you are going for recognition by sight, then you are creating a picture of the control in the documentation and that picture should be an exact match for the control or the visual match will not work. This means that you are going to want to match everything: font, color, style, etc. Often the best way to do this is with a graphic or a photograph of the control rather than by manipulating the font. There is no point in doing anything between these two, however. If the visual match is not complete than either the reader's visual matching will be confused or they will fall back on verbal matching, in which case the font choice etc is irrelevant.
#1: Imported from external source
by
System
·
2018-01-31T14:49:56Z (almost 7 years ago)
Original score: 8