Openshot-qt: Ask a Question

Created on 8 Jul 2018  Â·  11Comments  Â·  Source: OpenShot/openshot-qt

idk if this is the intent of the feature...

In help pull down>Ask a Question... brought me to this place. When I go to start new issue. It says request a feature or submit a bug... I used the last small link for submit a regular issue.

Is this what you guys intended? Or was it supposed to give an option for general question? (maybe limitation of github? but idk I'm not experienced in it.)

question

Most helpful comment

Anyways my point being, try to keep everything in 1 place.

Oh, no, I completely agree. And my suggestion was merely that the OpenShot website (http://openshot.com/) contain a page with a search form _for searching Github Issues_. The same way, right now, the Download area of the website is actually just a few pages of links to download files from Github.

Because right now, when you click "Ask a question" or "Submit a bug", you're taken to the exact same page. And there's no guidance there, it's just a list of issues, a search form, and a submit form. It's actually kind of a terrible interface, especially for non-developers.

One option would be to take people directly to the submission forms, like (now that I've created it) this form for "Ask a question". But it really isn't helping people to have them submit new questions (or bugs) without searching to find out whether their thing has already been addressed.

(Aside: The GetSatisfaction interface really does the guidance thing well. Their submission form is the search form. The only way to submit a new issue on one of their support communities is to first search for it, in the search field labeled "Find or start a conversation". Then, on the results page, there's an option at the bottom of the list (after the results) to "Continue Creating Conversation" if none of the results match what you want. It's an incredibly smart way to discourage pointless duplication of the same question/issue over and over again.)

So, in the absence of any way to do the same type of guidance within Github, my thinking was that we'd direct people to the OpenShot site, and explain that they should enter a search for their question or issue, then use the "New Issue" button if none of the results matches. Then when they enter their search, we deliver them to the Github Issues results page for whatever they entered. (IOW, that same page they're taken to today, but with the search already performed and just the results showing.)

I think that's doable with the Github API. In fact we could probably even turn off the default is:open filter, because there's no reason people shouldn't _also_ be searching for closed issues that match theirs. Only real problem is that it would mean modifications to the OpenShot website, and I still have no idea how anyone goes about making those happen. And also that we'd have to look at how this would work for users who are logged out of Github, or don't have an account at all. (Then again, that part's still no different from the way it works today so meh.)

Anyway, thanks for relating your Minecraft experience @Hunteil , input like that is always helpful. While I'm not a fan of the entire Agile development process, one of its concepts I do think has merit is "user stories", which are just what they sound like — fictional tales of various users who have some goal they want to achieve with the product. It's intended to keep focus on designing for the enduser and for the real world, not for a spec or a theory.


And just to prove that any good concept can be abused, here are some "user stories" from the Mozilla design document for the replacement browser theming API (Google Doc), since the old API went away with native extensions:

  • As a theme author I’d like to create a WebExtension that contains a manifest file which lists a set of properties and adheres to a schema definition and can be interpreted by the browser.

Okay... bit specific, but sure, whatever...

  • As a user I’d like the initial set of supported properties to be the ones as used by LWT: headerURL (‘images’ section), accentcolor and textcolor (both in the ‘colors’ section). NB: This marks the start of the Extend LWT epic (see below).

VERY specific and not really goal-oriented at all, but I suppose they count as user _needs_, sorta...

  • As a developer, if I have a ‘theme’ section, I’d like any other section (other than static resources) to be disallowed and ignored by the WebExtension manifest parser. This means no other APIs may be used, no background scripts defined, only the ‘themes’ clause and the optional set of static resources. This also means that as soon as a manifest contains a ‘theme’ section, it will henceforth be regarded as a theme.

OK, now you're just not getting it.

All 11 comments

I think this is what was intended.

However, if you have a suggestion regarding this, please feel free to put it on the table. :)

Also the thing is - you can basically do 2 things:

  1. Request for a new feature
  2. Report a issue in OpenShot

If none of that really fits your need, you can delete the form and submit your own custom thingy (which is what you seem to have done). Questions and thanks and "Look I made this with OpenShot!" are great too! :)

@ferdnyc @DylanC - Perhaps we should add 'something else' that will lead to a blank form, too?

@peanutbutterandcrackers - Maybe "Ask a question" would be something good to have?

@DylanC - Absolutely! And also "something else". There is always "something else". :D

Oh, if "Ask a Question" directs users here, we should definitely have an "Ask a Question" issue template. I'll put together something simple. (It's still questionable whether Github is really the best approach to question-and-answer support, but it's all we have at the moment.)

I'd be tempted to direct users right to it (vs. dropping them into Report a Bug if they choose that menu option)... but I'd _really_ prefer we encourage them to search existing issues, before opening one of their own that'll likely be a duplicate. I'm not sure there's a good way to do that via Github.

We might be able to put a search form on the OpenShot website that searches Github and drops them at the Issue search-results page, then they can open a New Issue if they don't find what they're looking for in the search. We could have the OpenShot menu options send them to _that_ form, instead of directly here...

@Hunteil : Out of curiosity, did you have a question? _Other than_ your question about the "Ask a Question" process, I mean? :laughing:

Never mind, I just spotted #1815. :grin:

@ferdnyc - I totally agree with you, sir! That would be neat!

For the time being, though, I think this can be closed, yes?

@ferdnyc - I think so at least.

Yea close this. And I asked questions already.

btw, Minecraft back in the day did a 1 place github style thing. (can't remember name) But overtime they migrated the bugs, questions and suggestions to different portals & separated the tracking function to other places I couldn't find. Which was disappointing b/c what they had setup worked really well. It felt like those other portals became fan driven and ultimately ignored over time...then more portals opened and over time it felt like they pushed out all the cool ideas and made it look like they cared but didn't. But it might have been they spread things out too far or microsoft idk. (not bad naming them, I know they own this too now lol) Anyways my point being, try to keep everything in 1 place. The more communities, the more you spread yourself thin. Suffered that myself in running other groups myself. FB, forums, discord, like 10 FB groups and a website for 1 community for a common goal... Just too much. So I figure repeating lessons like that must be useful to share lol.

Anyways my point being, try to keep everything in 1 place.

Oh, no, I completely agree. And my suggestion was merely that the OpenShot website (http://openshot.com/) contain a page with a search form _for searching Github Issues_. The same way, right now, the Download area of the website is actually just a few pages of links to download files from Github.

Because right now, when you click "Ask a question" or "Submit a bug", you're taken to the exact same page. And there's no guidance there, it's just a list of issues, a search form, and a submit form. It's actually kind of a terrible interface, especially for non-developers.

One option would be to take people directly to the submission forms, like (now that I've created it) this form for "Ask a question". But it really isn't helping people to have them submit new questions (or bugs) without searching to find out whether their thing has already been addressed.

(Aside: The GetSatisfaction interface really does the guidance thing well. Their submission form is the search form. The only way to submit a new issue on one of their support communities is to first search for it, in the search field labeled "Find or start a conversation". Then, on the results page, there's an option at the bottom of the list (after the results) to "Continue Creating Conversation" if none of the results match what you want. It's an incredibly smart way to discourage pointless duplication of the same question/issue over and over again.)

So, in the absence of any way to do the same type of guidance within Github, my thinking was that we'd direct people to the OpenShot site, and explain that they should enter a search for their question or issue, then use the "New Issue" button if none of the results matches. Then when they enter their search, we deliver them to the Github Issues results page for whatever they entered. (IOW, that same page they're taken to today, but with the search already performed and just the results showing.)

I think that's doable with the Github API. In fact we could probably even turn off the default is:open filter, because there's no reason people shouldn't _also_ be searching for closed issues that match theirs. Only real problem is that it would mean modifications to the OpenShot website, and I still have no idea how anyone goes about making those happen. And also that we'd have to look at how this would work for users who are logged out of Github, or don't have an account at all. (Then again, that part's still no different from the way it works today so meh.)

Anyway, thanks for relating your Minecraft experience @Hunteil , input like that is always helpful. While I'm not a fan of the entire Agile development process, one of its concepts I do think has merit is "user stories", which are just what they sound like — fictional tales of various users who have some goal they want to achieve with the product. It's intended to keep focus on designing for the enduser and for the real world, not for a spec or a theory.


And just to prove that any good concept can be abused, here are some "user stories" from the Mozilla design document for the replacement browser theming API (Google Doc), since the old API went away with native extensions:

  • As a theme author I’d like to create a WebExtension that contains a manifest file which lists a set of properties and adheres to a schema definition and can be interpreted by the browser.

Okay... bit specific, but sure, whatever...

  • As a user I’d like the initial set of supported properties to be the ones as used by LWT: headerURL (‘images’ section), accentcolor and textcolor (both in the ‘colors’ section). NB: This marks the start of the Extend LWT epic (see below).

VERY specific and not really goal-oriented at all, but I suppose they count as user _needs_, sorta...

  • As a developer, if I have a ‘theme’ section, I’d like any other section (other than static resources) to be disallowed and ignored by the WebExtension manifest parser. This means no other APIs may be used, no background scripts defined, only the ‘themes’ clause and the optional set of static resources. This also means that as soon as a manifest contains a ‘theme’ section, it will henceforth be regarded as a theme.

OK, now you're just not getting it.

Was this page helpful?
0 / 5 - 0 ratings