@zeeglen: The system designers did not mention that important little fact in the user manual...
I'm happy to hear that th emanual itself was well written -- but you highlight another problem area in that manuals are often drafted by people who know the system intimatly -- it's always a good idea for someone who DOESN'T know the system to try using the manual to work out where problems may hide away.
"I can't comprehend why manuals are not submitted to a native reader for a final proofing step."
Having been tasked with translations on several occasions, things are slightly different:
Whether you have a native proof reader or a native speaker (writer) doing the translation, there is an additional require- ment for this person: knowledge of the matter handled. I had native speakers injecting 3 major contortions within a single paragraph - and this was one of the better cases...
On the other hand, when I was reading a lot of datasheets from Sie... and Bo..., it was clear that these documents were "thought" in German and spelled in English. As the swiss colleague already stated: you can understand them by translating word by word.
I'd hate to think that the cost of having a native reader check a manual would be a factor for a corporation. The cost of having a reader review and correct the document is tricial in comparison to the product support costs of managing the mass of customers who require technical support because of an unintelligible manual and the lost sales from dissatisfied customers. Distributing an incomprehensible instruction manual is product marketing suicide.
@DrQuine: I can't comprehend why manuals are not submitted to a native reader for a final proofing step. Compared with the hardware and software development costs, the native reader review would cost nearly nothing.
I AGREE!!! I've never been able to understand this -- when you think og the time and effort involved in creating the product, why not go that one last bit and create a good manual.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.