3D models for naval architecture calculations

It is very important to get good support systems in any application that pretends to be useful to the user. In a previous post I have talked about it and I will not therefore insist .
There is much software developer whose native language is not English but they have to write help file in English. Surely their texts will not be perfect .
Lots of software users, whose native language is not English, have learned to use programs with help files in perfect English, difficult to understand for them.
And I ask my self this : Why would a user who does not understands properly a file written in perfect English , is able to correctly use an application ? . Why a user who is fluent in English can not read a help file written in broken English, and thus not being able to correctly use an application ? .
There is a part of the brain that has to do with languages, but there are other parts that should also be used to manage software .

 

OK rwatson. I see what you mean.

By the way, you wrote:

I don't think that is what is meant, but then I am a Dutch native, familiar with the traditions and jargon of Dutch boat builders.
The Dutch word "vlak" (as a noun) is the designation (jargon) of the outer surface of the skin (planking) below the waterline of a boat or ship. [Dutch Wikipedia article] The Dutch word "vlak" as an adjective translates to "flat" in English.
So what I guess they meant is the outer surface of the bottom (e.g. garboard strake), not necessarily being flat. :-o

There is after all quite some naval history and tradition in parts of the world where English is not the native tongue. Areas where Dutch or Spanish are spoken are fine examples of that fact.

So while I understand your point of view that it is sometimes hard to understand what an expert means, you might also appreciate the expert is trying to express himself in English as good as he or she can. Because otherwise you might be forced to learn Dutch, or Spanish, or Russian, or ... jargon, to be able to tap into multiple centuries of development, advancement and knowledge in naval research and architecture in those areas of the world.

 

Lets not confuse the ability to 'figure out' how software works, with a well written manual.

Given enough incentive, software can be used and understood without any documentation at all.

The reason the manual exists, is to dramatically reduce the amount of effort required by
1) Investigating purchasers
2) Committed users.


I can figure out how a program works by experimentation, but if I am evaluating several types of software, i will not pay a lot for something that will lead me down weeks of experimentation and frustration.

There are heaps of people who dont have English as a first language, and often they are dedicated enough to get stuck into the software prepared for the painful experimentation.

Good Documentation is done by developers who want to sell a lot of software and services to English speaking customers as quickly as possible.

If you don't want to sell a lot of software to English people, then don't bother with good documentation - its your choice.

 

Some interesting observations there, thank you.

My previous post outlines my point of view - if a developer wants to make it easy for English speaking people to assess and use their software, then they need to explain it. If they dont want to sell a lot of software to English speaking people - then dont bother.

Re the 'flat of bottom' points you made - it was as I expected - it is trying to convey an unexplained concept, badly.

Their should be another paragraph that says something along the lines of
"The reason that this is done, is that when calculating ......... and if you fail to correctly specify this parameter the program will ..... and here are two examples of the effect of ...."


Programmers often get upset when they are told that their 'explanations' are low quality. I often heard them say 'my software is totally intuitive" and "its easy to learn". There is no such thing as 'intuitive' when computers are concerned. The funniest thing to do, is to get two software developers who both write 'intuitive' software, to try out each others programs.

They will both give up in disgust within a short time saying 'this program is rubbish'


IBM, one of the biggest software sellers in the world, and English as well - spends up to a third of their development budget paying new users to trial the learning systems and documentation. But they are an exception - they really want to make a lot of money.

 

rwatson, I do not doubt it takes a good documentation, the hotter the better. In this case I totally agree with you. What I say is that in addition to documentation, brain, training and user experience are very important. We can not blame the documentation for our failures.
Another thought related to what you say : documentation with ungrammatical, it is very inconvenient, but, nevertheless, can still be a very good documentation to assist the user.

 

Hello Mr. Watson,
these are very important points that you make and the posting would deserve it's own thread. Here in this hijacked thread it is somewhat hidden.
English is not my first language, but it is the common way of communicating across the borders. Borders between countries and borders between naval architecture and software development. I too suffer if dutch or spanish idioms are used that I can not understand because they are literally translated.
Concerning software user manuals you should make a difference between free software and programs you have to pay for.
Best regards
Uli

 

Part of the problem perceived might very well be the inability of translating some jargon designations properly in the first place.

In an entire different field of work I once have been in a two-hour discussion on governmental level about a rule in the ADR treaty, finally concluding that there just isn't a translation of "shunting yard" from English to French that actually means the same thing.

So back to the example: how should it have been translated, so the translation would actually carry the same meaning?
And if/when such differences don't cease to exist, is a programmer/documenter to blame?
There aren't to much good dictionaries about, let alone thesauri, covering maritime / boat builder's "talk of the trade".

I do a fair bit of international work, most of it in English. That has proven to be working at its best when no one at the table has English as their native tongue. The same is valid for other languages and is the main reason my German partners prefer to use English and not German in a bilateral meeting, "so everyone is equal in being out of their comfort zone".

All of which might very well mean my appreciation for Spanish work translated into English is far bigger than mr. Watson's. He just might be the less lucky one here, just because his native tongue is English.

All wasn't bad in the days when concepts crossed the language barrier with Latin as its intermediate. (although I wouldn't understand any word of it in case someone would document their software in Latin, so perhaps we should stick to English anyway ;-) )

 

The secret to cross language translation probably isn't trying to 'copy' or 'translate' foreign language manuals, but rather, totally re-write the manual in the desired language using the topics list used originally. As noted previously - there are not only not equivalent words, but the local concepts, 'buzz words' and philosophy often don't 'travel'.

 

In terms of economics, this might seem to be true.

In practicality - its not really the case.

From a customer point of view, evaluating software involves a lot of effort. 'Free' software can take up 3-4 weeks of trial and error to resolve issues to even 'prove' the software value.

From a developer point of view - we may be talking years of their time, its true. Why do they release software for evaluation ? Out of the goodness of their hearts ? I don't think so. They are trying to get some income for their efforts, even if they don't admit it. Even if it is from ongoing support consulting for the product.

Sending out an incomplete software solution with little or poor education support ( manuals, tutorials etc ) , is like a cook sending out raw vegetables on a plate to a restaurant customer. They cant expect to be paid for going down to the market and paying for the vegetables, until they finish the job of cooking.

 

All opinions are respectable, rwatson, but do not know how you can talk so confidently of what the developers intended their actions or strategies.
I understand that some users may feel frustrated by not getting what they wanted quickly, but you always have to be objective and honest with yourself. Among other things to know what is the real problem and, therefore, apply the correct solution.
All computer programs, including Windows, have a beta phase in which they are exposed to the public to get the feed back from users. Often it is necessary to pay significant amounts of money to access these betas. They try, also, to purge help files, to identify user's gaps and generate good tutorials.
On the other hand, if you don´t like an application, whatever it is, do not buy it. In general, all them give the option of a trial period so that you get a perfect idea of what their strengths and weaknesses are.

 

After a lifetime of developing software solutions, I feel somewhat qualified to assert what the motives of people who spend years in front of the accursed flashing screens are.

If money with a bit of personal recognition are not the only motives to place software before the public , feel free to tell me.

Its not Some users - its ALL users who get frustrated when they dont get what they want quickly. Its nothing to do with any moral state of the user - the software is understandable, or its not. Developers choice.

You are preaching to the qualified here. I know exactly what goes on in 'software world'

The point I make emphatically is that Beta testing is NOT the place to start to develop instructional material. It is the place to make the material as good as possible. If you dont have a creditable instruction resource available by Beta test - you are just playing silly games.

I repeat - the instructions must be developed even before the software suite, because they are the plan, the guide, the direction of the whole enterprise from programmer to business manager to support person ( even if they are all the same person) .

Thats what I said before - if I dont like it, I wont buy it. Even more important, I wont even try it if the 'manual' is poor. Do I lose ?

Do I lose if I avoid weeks of painful frustration trying to understand the weirdness of strange 'buttons' on the screen ? NO!

Does the developer lose if no-one will undertake serious study. YES


Developers choice.

 

rwatson, given your vast experience as a developer, I can not tell you anything you do not know. It is likely that as the creator of ship models for calculations of naval architecture, yes I can tell you something. But you probably will not understand me because my English is bad. So I'll spare you the job.
Let me tell you a story : I know a person who, after several months of hard work, has been able to model a kayak and, of course, is desperate. I do not do more than repeat it should be noted that, besides the manual, he needs several other things. I advise him to reconsider how he is doing before blaming everyone walking down the Street.
"Superatis hostibus regium est abstinere". Cheers

 

I am also a software developer, in my case from the 1970s.

I find that starting with the user's point of view first is far better than trying to document something developed from the programmer's point of view. In the first case, the documentation makes sense to a user, and the user interface makes sense to the user. In the second case, nothing ever makes sense to any user, its just a bunch of random mysterious magic, and the source of personal frustration that turns to loathing.

My team is using TDD, test driven design, where we describe the user stories as tests, then sling the code to pass those tests. Seems to work well. Its getting pervasive in the web world: three examples are Etsy.com, gitlabs.com, heroku.com.

 

If its getting pervasive, its great, because its the only thing that works.

The number of software developers who know enough about interface design and product documentation is about the same as the number of lawyers that can tell the truth in front of a jury.