GreenPeace Team - I am with you!
@
PCI Compliance and file integrity monitoring
A short brief taken from http://www.lazarusalliance.com/horsewiki/index.php/PCI-11.5 says:
"Deploy file integrity monitoring to alert personnel to unauthorized modification of critical system or content files, and perform critical file comparisons at least daily (or more frequently if the process can be automated).
Critical files are not necessarily those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the merchant or service provider.
PCI-11.5: Verify the use of file integrity monitoring products by observing system settings and monitored files, as well as reviewing results from monitoring activities."
Details on this, and a company providing all this and more, coming up soon..
"Deploy file integrity monitoring to alert personnel to unauthorized modification of critical system or content files, and perform critical file comparisons at least daily (or more frequently if the process can be automated).
Critical files are not necessarily those containing cardholder data. For file integrity monitoring purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. File integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the merchant or service provider.
PCI-11.5: Verify the use of file integrity monitoring products by observing system settings and monitored files, as well as reviewing results from monitoring activities."
Details on this, and a company providing all this and more, coming up soon..
When you are finished...
So, you are a user.
And, Congratulations, you have just received your product CD along with the manuals, and you have started following them to the word (high hopes, eh!), believing each written word as if it were the word of God Himself.
You install the product, login, and start playing around with the different options to perform the desired actions. One flow in the manual is described something like this:
1. Do A.
2. Do B.
3. When you are finished, do C.
No! Please don't get a heart attack! The writer doesn't intend to finish you off - lest alone be harmed in any way!
All that the poor writer - who is surely lacking in words - wanted to say was something like this:
1. Do A.
2. Do B.
3. Once you have completed Step 2, do C.
So breathe, relax, and move on to step 3, without having to worry about you being finished.
PS: The writers who use this phrase ought to be ashamed of themselves if something happens to the user. I suggest they use the softer, easier words.
By the way, I am finished with this blog piece.
;)
@
And, Congratulations, you have just received your product CD along with the manuals, and you have started following them to the word (high hopes, eh!), believing each written word as if it were the word of God Himself.
You install the product, login, and start playing around with the different options to perform the desired actions. One flow in the manual is described something like this:
1. Do A.
2. Do B.
3. When you are finished, do C.
No! Please don't get a heart attack! The writer doesn't intend to finish you off - lest alone be harmed in any way!
All that the poor writer - who is surely lacking in words - wanted to say was something like this:
1. Do A.
2. Do B.
3. Once you have completed Step 2, do C.
So breathe, relax, and move on to step 3, without having to worry about you being finished.
PS: The writers who use this phrase ought to be ashamed of themselves if something happens to the user. I suggest they use the softer, easier words.
By the way, I am finished with this blog piece.
;)
@
Correcting ‘something that went wrong somewhere’, the four dots (....), and more
The aim of this blog is to introduce the work I do - and to lay some basic standards that must be used by the developers whenever they are playing with language, or grammar. This blog also has some content that has been picked up while reading the works of other Writers, and I would like to thank them for sharing and increasing my knowledge.
A Technical Writer (TW) - that's who I am.
And no, I am not a robot built on some new technology who can write. I am someone who writes about technologies and products in a way that even a layman can understand their intricacies and functioning.
As a TW, my official job involves writing the various Release Notes, Installation and Configuration Guides, Deployment Guides, Administration Guides, Security Guides, Performance Tuning Guides, Technical Reference Guides, and the Online Help for the various products. These, apart from editing (and sometimes writing) Tutorials, Case Studies, Technical Papers, White Papers, Web site content, and more.
The unofficial part is what makes my life interesting - and a whole lot challenging. This part involves dealing with developers - people who are going to give me the info I need to write my guides. Apart from playing with the products so that I can understand them - and thereby write - better, there are certain things that need to be discussed with the developers who write the code and understand the technology.
Error Messages: Just let them be small speed breakers - not roadblocks
While playing with a product, I need to click a lot of buttons, work with the menu options provided, and - oh woe is me! - view the sometimes confusing, sometimes horrifying error messages.
An error message I once encountered read "something has gone wrong somewhere". The utter shock and the feeling of despair attached to the message did not even let me react to it for a few moments. When I came to my senses, I had no option but to draw my pen (mightier than the sword) - and slash open the responsible developers' mind to fill it with a dose of some common grammar and ethical knowledge.
Error messages are supposed to soften the impact of 'something that has gone wrong' - they themselves must not add to the confusion. An effective error message must be able to guide the user to the proper action to be taken - if your UI design fails to do so. If your error messages are clear and concise, not only will they help the user move around the product with ease, but you will also be able to retain their interest and attention - thereby building loyalty.
Some standards to keep in mind while writing an error message are:
What Questions must the Error Message answer?
An error message should answer three questions, in this order:
1. What's the problem?
2. How do I fix the problem?
3. How do I avoid the problem in the future?
The answer to these three questions is enough information to inform and encourage the user to complete the task. It also subtly ensures users that they are dealing with a competent, trustworthy product.
What must be the tone and voice of my error messages?
You may lose the user if the voice of an error message is not pleasing. The user has done something that has resulted in a bug, which displays the error message. Now, if your language is also not friendly, the user may choose to stop using your product.
The error message must sound like an advice from a patient friend - not make the user feel like a patient being treated by an irritable doctor. A few do's and don'ts regarding the error message voice are provided below:
Do
Don't
Where must I place the message, and in what format?
The error message must not be such that it makes the users waste their time by forcing them to investigate what went wrong. The placement must be pleasant, and at a place where the users may not have to strain their eyes. The most effective placement of an error message is within a JavaScript pop-up, which the user must acknowledge and close before it's possible to proceed. You are probably familiar with the standard gray JavaScript boxes that pop up in the middle of your screen any time you make a potentially erroneous decision.
For maximum readability, stick with basic sans-serif fonts in dark, basic colors (such as black), and use a 10-point (or larger) font size.
Must the Length of an error message be fixed?
The length of an error message is not so important as the message being concise and to the point. Limiting the length of an error message should not be your first priority.
Colons in the field names
The correct use of colons is something I have tried to propagate since I started to write, - and sadly, still have to continue doing the same. As per the rules, in English-language, no space is placed before a colon and a single space is placed after it.
For example, 'Star Wars Episode IV: A New Hope'.
With the above example, I fervently Hope that all developers, whenever they are labeling fields on the UI, will stop using something like Name : ___' - and Start Using 'Name: __'.
Consistency of Button Names
Most of times, a big project is divided into smaller modules, each of which is handled by different developers. Though the management of the project becomes easier, the language consistency goes for a toss due to the inclination and style preferred by the different developers.
For example, one may feel that using OK/Cancel combination is correct, while another may feel at ease using Yes/No.
This inconsistency in naming the buttons (a Yes/No combination on one screen - and an OK/Cancel on the next) - if not corrected in time, may become an irritating experience to the new user. The only way out, I feel, is to set up certain standards and practices about the usage of these names, and then make the developers stick to these rules.
The Ellipsical Orbit
Another commonly (mis)used element of grammar that I have come across on various screens and error messages is the Ellipse (...).
Ellipses are a series of dots used to indicate the omission of words or paragraphs from quoted material.
Basically, from the UI perspective, the places I have seen ellipses being used are with the 'Browse...' option, or to indicate that some more options are provided in a certain sub-menu option.
Do not use more than three dots '...' in such cases.
A Technical Writer (TW) - that's who I am.
And no, I am not a robot built on some new technology who can write. I am someone who writes about technologies and products in a way that even a layman can understand their intricacies and functioning.
As a TW, my official job involves writing the various Release Notes, Installation and Configuration Guides, Deployment Guides, Administration Guides, Security Guides, Performance Tuning Guides, Technical Reference Guides, and the Online Help for the various products. These, apart from editing (and sometimes writing) Tutorials, Case Studies, Technical Papers, White Papers, Web site content, and more.
The unofficial part is what makes my life interesting - and a whole lot challenging. This part involves dealing with developers - people who are going to give me the info I need to write my guides. Apart from playing with the products so that I can understand them - and thereby write - better, there are certain things that need to be discussed with the developers who write the code and understand the technology.
Error Messages: Just let them be small speed breakers - not roadblocks
While playing with a product, I need to click a lot of buttons, work with the menu options provided, and - oh woe is me! - view the sometimes confusing, sometimes horrifying error messages.
An error message I once encountered read "something has gone wrong somewhere". The utter shock and the feeling of despair attached to the message did not even let me react to it for a few moments. When I came to my senses, I had no option but to draw my pen (mightier than the sword) - and slash open the responsible developers' mind to fill it with a dose of some common grammar and ethical knowledge.
Error messages are supposed to soften the impact of 'something that has gone wrong' - they themselves must not add to the confusion. An effective error message must be able to guide the user to the proper action to be taken - if your UI design fails to do so. If your error messages are clear and concise, not only will they help the user move around the product with ease, but you will also be able to retain their interest and attention - thereby building loyalty.
Some standards to keep in mind while writing an error message are:
What Questions must the Error Message answer?
An error message should answer three questions, in this order:
1. What's the problem?
2. How do I fix the problem?
3. How do I avoid the problem in the future?
The answer to these three questions is enough information to inform and encourage the user to complete the task. It also subtly ensures users that they are dealing with a competent, trustworthy product.
What must be the tone and voice of my error messages?
You may lose the user if the voice of an error message is not pleasing. The user has done something that has resulted in a bug, which displays the error message. Now, if your language is also not friendly, the user may choose to stop using your product.
The error message must sound like an advice from a patient friend - not make the user feel like a patient being treated by an irritable doctor. A few do's and don'ts regarding the error message voice are provided below:
Do
- Make your tone warm and personal by using personal pronouns as “you” and “your.”
- Take the responsibility of the error - do not blame the user.
Don't
- Do not use language that makes users feel that they are being shouted at. Shouting may be perceived when an error message contains exclamation points, long strings of capital letters, and bright red or yellow icons such as stop signs or yield signs.
- Do not use urgent or excited terminology such as “fatal,” “critical,” “severe,” “failed,” or “terminate.” Calm language is more likely to produce a calm reaction.
- Do not use techie jargon, code, or abbreviations. Humans are reading the error message, so use language a human will understand.
Where must I place the message, and in what format?
The error message must not be such that it makes the users waste their time by forcing them to investigate what went wrong. The placement must be pleasant, and at a place where the users may not have to strain their eyes. The most effective placement of an error message is within a JavaScript pop-up, which the user must acknowledge and close before it's possible to proceed. You are probably familiar with the standard gray JavaScript boxes that pop up in the middle of your screen any time you make a potentially erroneous decision.
For maximum readability, stick with basic sans-serif fonts in dark, basic colors (such as black), and use a 10-point (or larger) font size.
Must the Length of an error message be fixed?
The length of an error message is not so important as the message being concise and to the point. Limiting the length of an error message should not be your first priority.
Colons in the field names
The correct use of colons is something I have tried to propagate since I started to write, - and sadly, still have to continue doing the same. As per the rules, in English-language, no space is placed before a colon and a single space is placed after it.
For example, 'Star Wars Episode IV: A New Hope'.
With the above example, I fervently Hope that all developers, whenever they are labeling fields on the UI, will stop using something like Name : ___' - and Start Using 'Name: __'.
Consistency of Button Names
Most of times, a big project is divided into smaller modules, each of which is handled by different developers. Though the management of the project becomes easier, the language consistency goes for a toss due to the inclination and style preferred by the different developers.
For example, one may feel that using OK/Cancel combination is correct, while another may feel at ease using Yes/No.
This inconsistency in naming the buttons (a Yes/No combination on one screen - and an OK/Cancel on the next) - if not corrected in time, may become an irritating experience to the new user. The only way out, I feel, is to set up certain standards and practices about the usage of these names, and then make the developers stick to these rules.
The Ellipsical Orbit
Another commonly (mis)used element of grammar that I have come across on various screens and error messages is the Ellipse (...).
Ellipses are a series of dots used to indicate the omission of words or paragraphs from quoted material.
Basically, from the UI perspective, the places I have seen ellipses being used are with the 'Browse...' option, or to indicate that some more options are provided in a certain sub-menu option.
Do not use more than three dots '...' in such cases.
A SocialTwist!
Get everybody talkin' about your blog! Get the Free Tell-A-Friend widget for your blog/site at http://tellafriend.socialtwist.com
So what topics I will cover...
This blog will cover my thoughts and ideas on:
- Using Web 2.0 technologies for application development.
- Heuristics.
- Java-based application servers and related stuff.
- User interface technologies involved in Web 2.0 application and site development.
- Offshore and outsourced product development services.
- High value IP-led technology consulting for building and optimizing Java middleware applications.
- Web 2.0 based Software platforms that allow you to organize all of your media in one place, on your desktop — and share it with people you choose.
- Web 2.0 based jumpstart platforms that quickly build social networking advantages into your online shopping site.
Hi!
This one is going to be for writing purely technical articles/thoughts/ideas etc. - been long I have thought about it. For fluff stuff, like poetry, dear diary, etc - check out http://thequillersstylograph.blogspot.com/
Let's start.
@mit.
Let's start.
@mit.
Subscribe to:
Posts (Atom)
