search

webcompat / simplebug

A simpler interface for Bugzilla web compatibility issues.
Mozilla Public License 2.0
4 stars 4 forks source link

Simplebug home page should return an explanation of the project. #29

Closed karlcow closed 10 years ago

karlcow commented 10 years ago

When we are reaching http://webcompat.com/simplebug/ We get the generic page. We need to create something which is more explanatory for the visitors who would be chopping off the id of the URI.

miketaylr commented 10 years ago

Possibly:

By default, /simplebug/ loads the explanation page. We have a (clientside) router listening for URLs like /simplebug/123453/ that displays what we have now. Those URIs might be less fragile than an id param at the end (maybe).

Otherwise, We could have some explanation text up top in a div that is only visible if ?id is null/nonexistant. And the rest of the current fields are only invisible if an ?id exists.

karlcow commented 10 years ago

the router listening for /simplebug/moz/123453/ would be nice indeed. It would give us more flexibility for the future.

  1. Changing the framework
  2. Adding more partners

About 2.

Either simplebug becomes generic and have its own bug reporting system for everyone and we can have simplebug/1/ and/or simplebug/ms/1/ and simplebug/o/1/and simplebug/ch/1/ etc if we have to plug in each bugs system.

About loading the explanation page, yes that should be. In fact index.html should be plain HTML calling HTML and CSS and looking at the URI to apply the script if necessary. It's a nicer fallback story than the current one.

Also having URIs without the ? might be slightly easier to bake the static Web site with a cron or anything if we need.

miketaylr commented 10 years ago

OK. I've mostly got this written in a "backbone" branch. Right now if you hit the "index" route, it will show some text (just placeholder right now--hoping someone can write this for me). There's also a route for /#moz/124453 which basically does everything that the current iteration does. I still need to wire up the actual API calls, etc.

It does use hash URIs, I don't know if that's a concern. We could of course use pushState, but old browsers don't support that, and we want to support old browsers.

miketaylr commented 10 years ago

One more note--the default index.html text that is shown is all static HTML + CSS. The /#moz/234354 routes, however, are generated on the fly using underscore templates and the bz api.

hallvors commented 10 years ago

I like #moz/234354 since we get a vendor-specific part in it - but I think we've sent out a couple of ?id= URLs to developers already, so I hope you'll keep them working ;-)

miketaylr commented 10 years ago

Yeah, wondered about that. :) Maintaining backwards compat shouldn't be impossible.

karlcow commented 10 years ago

not very found about the hash sign in URI, because it creates plenty of secondary issues down the future alley. A hash is a pointer in one unique document, which means you can't really handle it on the server side with HTTP redirects. if we come up with something which is a static version of it one day. It will make it even harder. Is there a reason why the hash sign has to be in the URI? Imposed by the framework?

karlcow commented 10 years ago

?id=123456&vendor=moz could be used too.

miketaylr commented 10 years ago

Is there a reason why the hash sign has to be in the URI? Imposed by the framework? Imposed by the framework, kind of. If pushState is supported by the browser we can use real URIs (assuming we build a server-side component to serve the right assets for any of those URIs).

Trade-offs of doing client-side apps, I guess. I'd like to finish what I've started, if only to serve as a learning experience. We might decide it's not worth it (which is fine by me).

miketaylr commented 10 years ago

Does anybody want to write the text for this?

karlcow commented 10 years ago

I will give it a shot.

karlcow commented 10 years ago

OK something along:

<!DOCTYPE html>
<html>
<head>
    <title>No More Web Compatibility Issues</title>
    <meta charset="utf-8">
    <link rel="stylesheet" type="text/css" href="">
</head>
<body>

<header>
   <h1>No More Web Compatibility Issues</h1>
</header>

<article>
<section class="intro">
   <p>One of your Web site users can not access or has a bad experience on your Web site. Someone took the time to fill a report to explain, analyze and sometimes suggest how to fix it. Often the bug reporting system at browser vendors can be confusing or overwhelming, we created a simpler interface with the information you need for communicating inside your company.</p>

   <p>The goal is to make your Web site reachable and usable by a bigger number of users. We can help.</p>
</section>

<section class="contact">
   <p>If you are still confused by this site or have difficulties to understand its content, you can reach out to us <a href="http://twitter.com/MozWebCompat">@MozWebCompat</a>.</p>
</section>

<footer>
<p>This Web site has been created by the <a href="http://webcompat.com/">Web Compatibility</a> work in 2014. This effort has been initiated by <a href="https://wiki.mozilla.org/Compatibility/Mobile#People">Mozilla Web Compatibility community</a>.</p>
</footer>
</article>
</body>
</html>