#Organizational Questions: what is the best way to organize this information to ensure that people are helped as effectively as possible?
should we split the errors by windows/mac/linux, or by error type (listed in descending order of cases)?
Should their be entirely different guides for debugging Mac and Windows?
#Errors I know of
- app.db
- proxy/firewall
- I ask for the app.log, but so far that hasn't resulted in much useful info
#Resources debugging windows
#Draft
You've downloaded Studio and have maybe even started working on a project, but something is wrong with the program (Oh no!). It may be crashing, showing a blank screen, or ____. This guide will help you figure out what is wrong, and will help you solve the problem.
Not only the users, but we also have to be helped as effectively as possible 😏
I would love to see some paragraphs, that make it clear, that we need more information than "ugh, the program doesn't work".
Like I did at the start of the Windows Troubleshooting draft.
The way I wrote it maybe too much, but something in that direction would be great.
We could save some iterations in communication if the first mail/ticket/issue contained more helpful information.
Yes and no: depends on the definition of
debugging.General "debugging" (like Windows Troubleshooting: what is your problem?, applying shapeindex, dropping unnecessary attributes, ...) , that in reality applies to all operating systems, should be keep together, but with emphasis on the differences, e.g. paths.
Real software debugging (Part 1 and Part 2) that gets down to nitty gritty low level details requires completely different approaches per OS and is for tech savy users only.
These two types of debugging guides cannot be combined.
I think they should not even be on the same guides page.
This would probably just confuse the average Joe.