Modern testing for modern stacks

We have gotten into the habit of thinking deeper about one topic on a weekly basis. We pick topics based on anything interesting we read - so the topics can range from 'how to express the value of testing' to 'Dieter Rams' design principles' to 'effective remote work habits'. Employees are guided to spend no more than one hour researching the topic online. The emphasis is on coming up with their own ideas and interpretations. We then meet as a group to exchange ideas. I love this habit and consider it one of the more unique benefits you will enjoy at Qxf2.

How to write documentation for people who do not read?

8-August-2017

I found this talk interesting: link

Our thoughts

Avinash

I had an idea that this talk would be more about how we go about how we could write good blogs or document but it was nice to find that that the author speaks about how to write good code too. One thing I learnt after I started writing blogs and code at Qxf2 was to think about the different audience who would read or use the code. We need to consider all the people whom we target. Also, a good document doesn't mean just good English, as the author says we need to consider that most of the people just scan through your documents. So we need to put out the information in a best possible ways, like using images, bullet points, smaller paragraphs etc. Also, it was nice to see the examples on why to show good error messages in your code. At Qxf2 I guess we can still add more images to the blogs

Annapoorani

I can compare this with my previous experience.While correcting answer sheets if it's readable and presented neatly then it gives good impression. While writing blog the first paragraph we write here is why do I write this?So if we are searching in the Internet we just read the review and we go accordingly.As the author said document should be readable,Not like paragraph it should be in points.If we are writing the blog of how to rectify the error ,then if the user is searching with same issue ,they should find the document is useful and get rid of it.If we don't mention the document in a proper way then our document will fail.

Smitha

This is a good video where one can consult on how to write or read better. I like the various ideas the author has shared in the video. The F shaped pattern scan, the usability bullet list which is better than a paragraph. He's given a good set of examples. I could relate the documents that I have written so far. The code snippets should be a copy paste. The $ example is so true. I agree that we give error messages should be appropriate. It should solve the problem for the user.

Indira

I like this video very much. I agree that before starting documenting anything, we need to think in user perceptive, first we need to decide who should be reading this and why they're reading it. When we know this it will help us to define a proper document structure. When ever we search in the web we just scan for the content we want and we never bother to read each and every word. So, the first two paragraphs and first 3-4 words of every paragraphs are critcal to state the most important information. I agree that providing proper subheadings and bullet points focus our attention. In Qxf2, we are making sure that there is good SEO to boost our website's rankings in search engines, maintaining good meta data, maintaning good readablity. If the posts is lengthy we are breaking it into a series of posts. We are talking about the problems and the ways to solve it and step-by-step procedure to help users accomplish tasks. Also we are structuring our paragraphs in the inverted pyramid style ie.,stating the conclusion first, then supporting it with the sentences that follow.

Rohan J

I found the video to be good, the presenter has made very good points giving examples about different documentations. I too find it difficult documentations when there are large paragraphs which are not formatted. So documentation should be well formatted, there should be bullet points and code snippets wherever required. I have found in some documentation that it's not possible to recognize between hyper links and normal text. Also in the video, he mentions that some people blindly copy paste the code from documentations without reading it and then they face issue with typos, syntax errors and the main thing the prerequisite packages which are required while running code are not available on their system. So a documentation should guide you with the errors that you might face or the packages which you require before running code.We have a good Readme i can say, I completely agree that documentation should be written from a user perspective and each line should have characters between 65-90.

Nilaya

I was actually surprised to see this video, most of the human have a tendency to ignore the lines while reading.The F pattern given was really interesting.Author has given really very good points to follow while documentation.So that at least reader will not miss any important point.Very good article indeed.

Raji

According to usability researchers, the way users read on web is just scanning for the content they want. I would agree with F pattern as discussed in this topic about so much text is being ignored.Hence it is good to practice these simple techniques for effective write up. Here are some key tips for effective documentation as per the video - Add images with annotations , code snippets, paragraph shapes, minimal and meaning full text, bullet lists, clear font formatting, indexing, key words, good headings, smaller sections, don't go for too much wide text, table of contents for different sections . I learned little bit about SEO techniques , I can say this video is connected with me well.

paper cut