10/03/2012, 10:51 PM
Here's something that annoys me when I visit the forums. When you see someone has a problem, it's usually a question, a couple of attempts at identifying the problem, and then usually someone comes and says "you'll have to Doctor". I feel that problems are not being solved, but being delayed instead. For issues that result from actual hardware failure, this is acceptable. But for the rest of the cases, it isn't the best way to go. Doctoring should not be the standard response to problems. It should be the last course of action when all options have been exhausted. Instead, what should happen is the issue should be thoroughly diagnosed and identified, and a solution proposed. Only after possible solutions have been attempted should the last effort be Doctoring.
This problem stems from the fact that most of us here are just consumers, taking advantage of the homebrew goodness. But when things turn for the worse, the consumers are stuck, not knowing how to fix the problem, and in turn come to ask here. Now that HP has discontinued their chat support, we are effectively the only readily available resource for helping solve webOS problems. It's great to see everyone help out, but I sense a lack of standard procedure to diagnosing problems. That leads to random guesses (which is OK), that quickly falls to "Doctor it!" (which is not). Those of us who like to poke around at the insides of webOS try to help too, but we're not always available. It's important that when we are available, we're given the information we need to start diagnosing the problem.
What really irks me is people think the standard procedure for fixing webOS problems is to just Doctor the device and hope for the best. I see quite a few help requests indicate that the owner has already Doctored their device, and their issue isn't fixed. It isn't helped by the fact that Palm recommends Doctoring both on their support site and on their chat. Doctoring, in my opinion, is quite detrimental. Every time a device is Doctored overwriting and formatting the flash, and writing new firmware, wears out the chips that store those data. In addition, all configurations on the device is lost, and only so much can be restored from the cloud backup. Not to mention all the time it takes to restore all the apps. Come on, we're homebrewers! Someone knows how to dig into the problem. The Doctor is great as a reference, but using it too frequently I would consider it as abuse.
Here's my story. I have Doctored my TouchPad for two times total. For the same problem. It was the bad WiFi issue, where after using the TP successfully for a few months, out of the blue it would quit connecting to my home network.. I did try to diagnose the problem, by swapping out some binary files for others. I eventually ended up using the support chat, where they told me to Doctor. I ended up doing a "delete data", and after a bit of difficulty managed to get things working again. A few months later, the same problem occurred. Knowing the solution to the problem the last time, I Doctored again. It worked. For a day. I tried other Doctor versions, then OTAing off of whatever signal I got. Nothing worked. I then went on to search the problem out, and on an Android forum it was discovered that the TouchPad only likes wireless channels 2-4, and had trouble connecting to most other channels. I changed my router channel to 2, and presto, it worked fine ever after. I regretted Doctoring, and I wasted lots of time and Internet bandwidth by having to reconfigure my TouchPad and downloading back apps. I've learned my lesson, and I now rarely suggest Doctoring, and even when I do suggest so, I use a qualifier such as "may".
What you can take from that is regardless of what tech support tells you, Doctoring may not fix certain problems, and may rather be a waste of time. In fact, it is likely to be overkill for many problems. Got a botched patch and device won't boot? Track down the bad file and push a new copy from the Doctor archive (note I did not say "Doctor the device"). Got a corrupted file system? Boot from the installer ramdisk and do a fs-ck. Stuck on USB Recovery mode and can't boot (actual case that just occurred again earlier today on the forums)? Use the command line to boot and start ordering replacement parts (Doctoring won't even help in this case). Some times it's just those really simple root causes that create problems, and by knowing the right thing to do one can save oneself a trip to the Doctor.
Now granted, not everyone is comfortable trying to dig into their device to try to find the right solution. And I think everybody here understands that. I might be able to mess around with bootloader commands, while the next person don't know and won't touch them lest they brick something. That's OK. What's important is we have enough information to figure out what's wrong. So I'd like to suggest a standard issue submission format to make it easier to diagnose problems.
Guidelines to Making a Great Support Request
- Make a detailed description of the problem. That means describe what you're trying to accomplish, what is preventing you from accomplishing it, and what you have done to try to solve the problem. Is the device on (power off, standby, or active)? Can it recognize your input? Is there an error message, and if so what exactly is the message, and along with it what sort of visual cues are there? What app is this? What makes you think something is wrong?
- If the problem is not trivial to describe, include a picture. It is especially helpful when there is an error message of some kind, as in addition to seeing the original error, the surrounding chrome may provide clues to what program or part of program the problem is stemming from. That said, don't include a screenshot for really common errors, such as "Too Many Cards", "Application Database Full", and "Not Enough Space", as people have probably seen them many times and they don't actually provide any useful info.
- Search around. If you found some posts that may relate to the problem, link to them. And that includes anything external to webOS Nation. I'm not a moderator, but I feel that the more relevant resources are available, the more helpful it will be to people who are trying to diagnose the problem. If you've found some troubleshooting instructions, follow them and report what you've done and the results. If the steps have modified your problem, reflect that.
- Attach logs. Try to obtain logs if you can. Logs provide additional information about a problem that may in identifying the source of the error. If your device is in generally working order, follow this detailed guide on how to post logs.
- Grammar: You're asking others to help you solve a problem, so be sure that other people can read it. By writing sumthng dat lookz lk thss, plsssszzszs11!!1! will not help. So actually write out full sentences with correct capitalization and commas, and read it over to make sure you yourself understand it before subjecting others to it. Messages that lack an attempt to write something comprehensible will be quickly ignored due to it being hard to read. If your native language isn't English, try your best to write something that makes sense. If you have to, attach a message in your native text. webOS Nation is global, and chances are someone can read your language and help you solve your problem.
- Use general etiquette. Don't post the same question multiple times in different subforums, and be patient while getting an answer. If your post doesn't get responded to for a week, prodding it a little is acceptable. Just be sure to engage in the problem solving process. We can't do all the work for you.
By following these guidelines, you'll help ensure that your problem gets solved faster and with more accuracy. One last thing I would like to suggest it to users to get more familiar with their devices. By that I don't mean know what all the buttons do and where the microphone hole is (even though you should know the distinct outwards features of your device), but to be more familiar with the operating system, on a deeper base. That means knowing that webOS is a Linux derived operating system, and know that apps go into /media/cryptofs/apps/usr/palm/applications. Read up on the basics of Linux directory structure; grab a copy of Internalz Pro and look through the files; learn how to perform basic Linux commands; peek at some of the built in apps and scripts. webOS has quite a large amount of textual code, and they are very often documented. Knowing this is advantageous because you can do some of your own digging when a problem occurs, and have an idea of where it's coming from. It'll also help troubleshooters when you can provide them with a rough idea of the problem source. Before I got my TouchPad last August, the only thing I knew about webOS was it was introduced in 2009, made by Palm, and had some cool multitasking. I had only seen a Pre once. But through reading WebOS Internals, looking through Enyo source code, looking at random files on the device, and participating in helping others solve problems with their devices, I gained enough webOS knowledge to make my several patches and the Country Changer. While it's true I knew something about programming before I bought the TouchPad, and it helped accelerate my learning of webOS' structures, if I never bothered to look under the covers, I wouldn't be writing this today. It's never too late to start discovering and learning. After all, this is your device, and you own it, so feel free to understand what makes it tick. And remember, if you mess up a file, you can always push a replacement version of that file to your device and back to normal.
So in the end, let's adopt some proper problem reporting techniques, and understand our devices deeper. It'll result in less time wasted restoring data, and more knowledgeable users. The webOS homebrew community is known for its creativeness. Let's make sure we have more and become the most knowledgeable about our platform compared to other mobile users with respects to their platforms.
//End of impromptu essay writing