As you all know, a lot of questions on the site are being asked without proper information. For new or inexperienced users facing an issue, this is something I do understand. However, no matter how well we are trying to help them, a lot of questions will be cluttered with several comments asking for more information and the OP does not do exactly what we ask (e.g. dpkg -1 rather than dpkg -l), or replies in a comment similar to "I'm new to Ubuntu, I don't know how to do that...".

This is not efficient, it's discouraging a new user to run terminal commands, it's taking a lot of time to teach users how to do stuff in the terminal, etc.

That's why I was thinking about a dead simple system information tool, completely designed for use with AskUbuntu (or even Ubuntu forums). On the chat, I've had a nice discussion (starting here) on this with Alvar and this made me realize I had to post this on Meta to ask your thoughts on this. I may have missed another (failed) attempt in the past, or some of you might have serious concerns about the practical issues we will then face with it.

I'm posting my rough idea as an answer.

I'd like to keep this discussion within these boundaries (else, it would be going nowhere) before we're already designing and coding it:

  • Should we even bother creating one? Or is there a tool out there already?
  • Basics on UI: Wizard/non-wizard, One set of checkboxes or a "nice" UI, etc.
  • Basics on non-functional requirements: should it run on 10.04? should it be a "portable" app without external dependencies?
  • Basics on functionality to include: automatic upload of info? even automatic attach to question? how much of heuristics? warn the user about current state of the system?
  • Basics on safety: should it have the ability to do (usually harmless) changes? (modprobe this, restart that, run apt-get update, etc.)
  • What's are the musts, shoulds, coulds, wishes?
share
    
I love the idea. However it would be very important to clearly communicate to the user what information is going to be shared and of course personal information should be a no go. –  Octavian Damiean Jan 8 '13 at 12:32
5  
Why a separate app? Maybe just adding this to the System information application? –  Jorge Castro Jan 8 '13 at 14:19
3  
@JorgeCastro One of my thoughts too, yet... 1) how do we get a custom System Information application in the current Live images? and if we manage to do this by a new package, 2) it is confusing if one version of this application doesn't provide "AskUbuntu support" and another does. 3) not all DEs have the same System Information application, so this would needs us to expand the work to all... KDE, Unity,... –  gertvdijk Jan 8 '13 at 14:22
2  
You would just fix the existing System Information app to include the buttons you need. –  Jorge Castro Jan 8 '13 at 14:25
5  
@Jorge Castro: If you think a there is no need of a new app for system information, Please post it as an answer :) –  Tachyons Jan 8 '13 at 14:46
add comment

5 Answers 5

Yes, we should have one. A simple one.

Audience

  • New and inexperienced users.
  • Ready for first encounter with Ubuntu.
  • Ubuntu Desktop use related.
  • Running any supported Ubuntu release.

Idea / recipes

1, one, ONE single functionality: gather the information requested for in the Q. Following the KISS principle from head to toes.

A set of extendible recipes (or scriptlets) to gather a set of information and guide the user in what to gather. See below for some examples (mock-up). The tool may ship with let's say 50-200 common ones and they consist of four things: title, category, description, what/how to gather.

Experts on AU just ask for information in plain English and the tool is able to suggest the right recipe which the user selects based on words that actually exist in a dictionary.


mock-up

A very rough idea of what's in my head, mocked up quickly, should look a lot nicer after some UI designer created nice graphics:

enter image description here

Note (not yet drawn): the description of the recipe selected should be shown in the middle (now below the search suggestion box) along with a button "Yes, this one!", which will add it to the list on the right.


musts

  • A dead simple, clean and user friendly UI.

  • Limit it to what the user specifies (what is being requested for).

  • Transparency to the user. What is being gathered, and what isn't. E.g. description on recipe List of installed packages should be like this:

    This gathers the state of all known packages on your system. It does not include personal information, but it may reveal some of your personal preferences.

  • Ability to run on unsupported releases, with just one message: "You're running an unsupported release."

  • Static binary "portable" "runnable" version as well as proper .deb. Ship stuff we rely on, but which might not be available on all the systems.

  • Tested all the way down. Not crashing. Ever.

shoulds

  • Finding the right recipe(s) should work much like Synapse (image) or the HUD (image).

  • Use tools already available to do this job. E.g. Apport, as suggested by rafalcieslak.

  • A little bit of heuristic to ease the use. For example, don't even show a "save to file" button if it's connected to the internet and vice versa.

  • Basic integration with AU if internet connected. Upload button for large amounts, copy/paste Markdown for small amounts.

  • Ability to guide the user in transferring the output via a flash drive to another computer in case he's not connected. This includes cross-platform awareness (e.g. CRLF-line-endings) as the user might only have Windows to boot with an internet connection.

  • We maintain the set of recipes/scriptlets in the community and we can accept pull requests for improvements/additions. (see also could-have online database below)

coulds / future ideas

  • Hint some possible relevant recipes based on the selection of one or more.

  • Translations for the descriptions.

  • Minimal bootable CD that can chroot into existing installation.

  • An online database with some more and possibly updated bunch of recipes, GPG-signed by multiple trusted members making sure the commands are harmless, safe and useful. Public keys hardcoded into the tool.

  • Custom URI schema to use in the comments to ease the user finding the right recipe. It could also be used to specify arguments to the recipe (escaped properly - security concers here!) E.g. ausysinfo://recipe/a123/eth0 to run ip addr list eth0.

  • Unfoldable embedded terminal to show the user what is going on in the background, for example: screenshot of system update. This serves both the learning aspects as well as the transparency we need.

don'ts

  • "Hi there, what's your issue about?" it's not about issues
  • Trying to write code that would save braintime and outsmart humans. People are way smarter to see what's going on. Don't try to fit this heuristics in this tool, please. I want to vote for good answers, rather!
  • Dependencies on stuff unavailable desktop images of all supported releases. No shiny new Qt5 stuff, please! That would make it huge if we would need to ship it with it.
  • Gathering more information than requested. This will have the opposite result: taking a lot of time going through all the output.
  • Running arbitrary commands automated (e.g. fetching commands from comments). Big no-no to shell injection threats!
  • Allowing remote access tool. security concerns
  • Touching the system. even no to harmless changes
  • Attempt to extend a current tool. This is confusing "yes, I started it, but I don't see this button" "you need to install this plugin first...".
  • Attempt to include all possible commands we would like them to run. Instead of focussing on the numbers, it should focus on quality of the most common ones. Also, if it covers 90% of the now terminal-tasks, that's already very powerful. Aiming for the 99% is not what I have in mind - would be too hard.

Some of the above don'ts explain some key differences between my idea and George Edison's idea.

share
    
Awesome Idea!! I love it! –  Seth Jan 7 '13 at 23:46
    
Who can code this program? –  Alvar Jan 8 '13 at 1:17
3  
@Alvar I could, but that's not the point - being it dead simple just running some basic commands, redirecting output to a file... I think the design part is much harder as everyone should be able to run it effortless. Or else it's useless anyway. –  gertvdijk Jan 8 '13 at 1:26
1  
as it is right now, it's too complex. It should be more like, Internet problem, kernel problem, install went wrong, more user friendly. anyone should be able to use it, if you can read then you can use it. –  Alvar Jan 8 '13 at 1:47
    
@Alvar I'm not sure if I agree on this for the use on this site. However, we may go for a Wizard-like approach too and have a button "manual selection" there. Anyway, first let's see if we want the tool, then decide on the design. This UI in here is just a brainfart-level mockup. No need to rush into things. –  gertvdijk Jan 8 '13 at 2:19
    
The hint could also include an URL with the search parameters set OR even better: we mark a(/several) question(s) about BCM4311 that are good enough to be included in the hint. (a "have a look at these topics") –  Rinzwind Jan 8 '13 at 9:13
    
@Rinzwind Sort of agree to that. I've put this "hints" section down to could haves. Here's my view on this. It's on the edge of what it should do imo as it could change the use to this site. I really disagree with a troubleshooter and I don't want to to be a find the appropriate existing question. We should not prevent it to vote for good solutions/troubleshooting users are posting. –  gertvdijk Jan 8 '13 at 9:23
    
We should also automate the information upload step. It could be an optional thing you'd select using a check box. –  Octavian Damiean Jan 8 '13 at 12:50
    
I think the check boxes might have a downside, as new users that are requested information, may check all the check boxes to upload at once, this could be fixed by how the information is formated on the upload, but I agree with @Alvar on this, also users are likely to have one major problem to gather information for at a time (discourage questions asking about everything broken.) –  Mateo Jan 9 '13 at 3:58
    
IMO the tool should try to get data from the SE API in order to help ascertain what is needed based on comments, possibly formatted in a certain way. Also, can you make your post(or another post) community wiki? –  hexafraction Jan 9 '13 at 12:24
    
Sounds awesome, keep up the cool project. –  Mateo Jan 9 '13 at 20:44
    
@gertvdijk One answer marked CW is enough. –  hexafraction Jan 10 '13 at 21:28
    
@ObsessiveSSOℲ Executing shell commands via comments? let's ninja-edit for plain shell injection! –  gertvdijk Jan 11 '13 at 9:31
    
@gertvdijk I'm talking about using a comment to point to an existing info-gathering script, already having been approved via the LP branch, Github repo, etc, etc. –  hexafraction Jan 11 '13 at 12:49
    
@ObsessiveSSOℲ Yep, I that would be okay. Like ausysinfo://recipe/a123/eth0 <-- still room for a simple non-shell-injectable argument proposed here in chat. Eventually we could use built-in PGP keys of trusted members to run trusted, harmless, safe external commands from an online database (if internet-connected). –  gertvdijk Jan 11 '13 at 12:50
show 2 more comments

I personally think that there is no need for such a tool, for the following reasons:

  1. If the tool were too simple, the risk is to collect private information. Apport is a simple tool, and in fact most of the bugs reported using Apport are private.

    If we were using a tool like that, we would need the ability to mark questions private and/or have a special review queue to which only privileged users could have access. This is out of the scope of Ask Ubuntu.

  2. If the question requires too many specific information about the user's system, then it should be closed as too localized.

  3. I'm against this sentence:

    This is not efficient, it's discouraging a new user to run terminal commands, it's taking a lot of time to teach users how to do stuff in the terminal, etc.

    People are not forced to use the terminal. Most of the problems can be solved using graphical applications. Also, if explaining something takes really too long, either the question is off-topic (as specified in the FAQ) or the Ubuntu documentation should be used.

    The Ubuntu documentation is very well written and when it is incomplete, remember that every community member is free to propose changes. Instead of investing efforts in writing a new tool, you can expand the documentation.

  4. People who seek answers generally want to learn, not just to solve their own problems. A tool like the one proposed would hide the operation details, therefore removing the learning part.

    And remember that people who seek answers are not just people who ask questions, this is one of the basic principles of Ask Ubuntu.

share
    
Well written. There's a need for such a view on this here, thanks. Good points about private info collection and Ask Ubuntu priciples. While I still feel the need for one and I think the private info issue is easily solved, this deserves a +1 for keeping the heads up. –  gertvdijk Jan 9 '13 at 13:41
    
Many users chose ubuntu because it requires less terminal commands than other distros, Not every want to learn terminal commands. Ubuntu documentation is simple and useful but it is not replacement for QA +1 for second point and last paragraph –  Tachyons Jan 9 '13 at 14:11
1  
I sort of agree with the learning part. Remember that the tool I have in mind should be for new users only and this just aids in getting the information in the 1000s of Qs we're receiving about issues in their first experience and avoid a certain part of the abandonments. Once basic stuff works, they can move on to learning. –  gertvdijk Jan 9 '13 at 14:23
    
-1 for points 1 and 3. +1 for points 2 and 4. We don't have time to explain graphical ways around just to get lspci, IMO that what this tool is supposed to do. Go get what we would ask the OP for. I don't see the need for private when I would ask the OP and he would post all the output of the command. Just my opinion. –  Seth Jan 9 '13 at 16:32
add comment

Ask Ubuntu is not here to spoon-feed people into troubleshooting their problems. Ask Ubuntu is a Q&A site, people are expected to put effort into making their question useful, well researched, well specified, atomic and most importantly: useful to other people.

I see far too many questions of like this:

Title: Problem with Ubuntu wireless, and WoW

I just installed Ubuntu and my wireless isn't working [without including any details]. Also, can I run World of Warcraft?

Questions like these should be down-voted (or even closed). Don't hesitate to downvote a bad question, it doesn't cost any rep. We're here to help the community first, the lurkers second, and the OP third. Bad questions waste everyone's time, and they turn Ask Ubuntu into a low-quality wasteland.

Now imagine if the question had at the end the output of some sort of Apport-like debugging tool. Would the question be any better? My answer is no: it's still a bad question. It still needs to be edited to cut it down to only one question, to actually specify what the problem is, to demonstrate research, to have a specific question title. Otherwise, it's still useless to other people. For starters, how will other people suffering from the same problem even find the question?

So should we ask users to post the output of some sort of Apport-like debugging tool? Yes, but we shouldn't consider it a good question until the rest of the question is fixed. That debugging information may be useful to editors, but it may not be. Editors are there to improve a medium-quality question. OPs are expected to put a minimum of effort in first, though.


Other avenues, such as the ubuntuforums.org or the IRC channel are more appropriate for helping people step-by-step into troubleshooting a problem. I recognise that some people are completely unfamiliar with computer technology, and need that kind of help, and I'm really grateful for those who volunteer their time for them on sites like ubuntuforums.org, or even in person with Ubuntu Hour. On Ask Ubuntu, though, we're trying to reach as many people possible at once, rather than one-on-one support.

tl;dr: adding automatically collected system information doesn't magically make a question a good question.

share
1  
+1 for taking a broader look. "we're trying to reach as many people possible at once, rather than one-on-one support." <-- best part of your answer, imo! This makes me believe something fundamental has to change about what we should accept here as questions indeed. –  gertvdijk Jan 9 '13 at 15:29
    
Noo, askubuntu is spoonfeeding when compared to unix.stackexchange.com :p –  Tachyons Jan 10 '13 at 4:38
    
According to this comment in another question, it is mentioned that AU is a support channel mentioned in the installer. Can anyone shed some light on this? I think we're not a "drop your issue here" site and if that is indeed mentioned by the installer, that sould be changed. –  gertvdijk Jan 11 '13 at 15:00
1  
@gertvdijk: Here are some out-dated screenshots of the installer slides. Ask Ubuntu is called "the best place to get an answer about Ubuntu", which seems fair enough to me. It also mentions commercial support in the same slide. –  Flimm Jan 11 '13 at 21:02
add comment

Note: please see this question for further discussion.

Okay, so I decided to get something started here - no promises since I am a really busy man penguin. Without any further discussion, I present to you "Ask Ubuntu Troubleshooter":

enter image description here

The basic idea is that the application is a simple wizard with dependencies only on the base Qt5 libraries - which are set to be included with the upcoming 13.04 release.

You can find the code for the application here on Launchpad: Launchpad logo autroubleshooter

So here's where the community comes in:

What information / command output should be included with each of the options in the screenshot above? Feel free to edit this answer and add to the list below:

  • Graphics / display driver
    • lspci
  • Wireless connectivity
    • ifconfig

Feel free to add categories too!

share
    
Another way the community could help is by creating Debian packaging by following this guide. –  Nathan Osman Jan 8 '13 at 7:01
    
Wow, I appreciate you sharing ideas and even get started on something! However, I have my concerns about some key parts of your answer. 1) troubleshoot is what people do, 2) No fancy UI required, so Qt5 seems not a good choice for 10.04/12.04/12.10 stuff. –  gertvdijk Jan 8 '13 at 9:03
    
+1 for quickly starting , -1 for QT5 –  Tachyons Jan 8 '13 at 12:58
    
I think we should add something like lspci | grep Network and lsusb to wireless issues, because a fair amount of the questions relating to wireless is drivers issues. –  Seth Jan 8 '13 at 16:47
    
@Tachyons: What's wrong with Qt5? –  Nathan Osman Jan 9 '13 at 2:23
    
@iSeth: Feel free to edit and add them to the answer :) –  Nathan Osman Jan 9 '13 at 2:23
    
Never mind - I've switched back to Qt 4.x for now since that increases the chance the user will be able to run the app without any other libraries since the Ubuntu and Kubuntu CD both include the Qt4 libs. –  Nathan Osman Jan 9 '13 at 3:43
1  
@gertvdijk: The name is a bit misleading - the tool is only designed to gather information. It doesn't fix anything. –  Nathan Osman Jan 9 '13 at 3:46
    
@George Edison: Nothing wrong, but1) qt5 is not available in default repostory of 12.10 and older 2)kde apps will pull lot of kde dependancies,It will affect sisze of the app, Personally I prefer Gtk ui for ubuntu and Qt ui for kubuntu –  Tachyons Jan 9 '13 at 10:37
    
@Tachyons: I've switched back to Qt4 which is included with both Ubuntu and Kubuntu. We should be good now. –  Nathan Osman Jan 10 '13 at 1:22
    
@GeorgeEdison The name is one thing, but I'm very much against making the problem the centre of it all. It's very hard to limit the output of the tool to the useful set of things. "Wireless connectivity issue"... well that's lshw, lspci, rfkill, iwlist, NetworkManager, logs, firmware file listing, ... (endless) –  gertvdijk Jan 10 '13 at 3:30
    
@gertvdijk: Well then perhaps the tool should let the user pick the commands to run then. That way when the user runs into the problem and asks the question, we just tell them to use our tool to get the output of xxx and yyy commands. I'm just thinking out loud here. –  Nathan Osman Jan 10 '13 at 4:17
add comment

There is already a tool in Ubuntu that collects all the data that is useful for developers for having a glimpse of user's system state. Actually, that's what Apport does. Of course we don't need to collect debgging data, but things like package list, module list, or anything we may want can be obtained via Apport.

By no means can we ask anyone to run custom apport commands in order to get it to collect all needed data, this would be too confusing. But it may make sense to reuse existing hooks that can gather the data from system (and can already deal with privacy etc.).

I am not knowledgable about Apport, but I believe it should be easy to create a GUI wrapper over some of it's hooks (or maybe create some new hooks - if needed - that would be managed by apport?), so that we reuse it's potential.

share
    
+1 for mentioning to reuse stuff from Apport. Great suggestion. This could make a new application even thinner and just a flat UI skin. Good. Good. Good. –  gertvdijk Jan 8 '13 at 21:51
    
When you say we don't need to collect debugging data, perhaps you mean we don't need to collect stack traces and related technical data from program crashes? The rest of the data Apport collects seems quite relevant to providing support. I don't know if automated data collection will prove necessary or useful for Ask Ubuntu, but if we're going to do it, it seems the task is largely already done in Apport. A related approach would be not to rely on Apport or use any of its code, but to write a new app that uses packages' apport hooks, so it automatically collects the same data as Apport. –  Eliah Kagan Jan 9 '13 at 0:49
    
except, I removed apport from my system to avoid vague crash messages. –  Mateo Jan 9 '13 at 1:38
1  
@mateo_salta That would likely not be an impediment to your using the hypothetical maybe-or-maybe-not-extremely-useful tool being discussed here. It seems to me that the new information reporter utility would more likely be a derivative work of Apport, or a totally new program, than a wrapper that requires Apport itself to be installed. Furthermore, removing Apport is totally unnecessary--you can get rid of all the messages by disabling just its automatic crash reporting functionality. –  Eliah Kagan Jan 9 '13 at 2:47
    
I'll do that next time @EliahKagan , this usage would give me reason to reinstall it. –  Mateo Jan 9 '13 at 3:51
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .