Compatibility/Mobile/2014-02-24

From MozillaWiki
Jump to: navigation, search 
Meeting: Mobile Web Compatibility Weekly
Agenda: https://etherpad.mozilla.org/webcompat
Chair: Karl
Scribe: Mike
Regrets:

Topic: next meeting

Next meeting: The next meetings will be on March 3, 2014

Bug Ahoy (mike)

FILE BUGS https://github.com/webcompat/bugsahoy


  • mike: I got the url. It is working. We need to figure out how we will advertise it. If you are offended with the design, just fix it with pull requests. Mike is explaining the way it is supposed to work.
  • blassey: It's very useful to get bugs fixed which are usually not on the priority list.
  • miketaylr: we sprinkled bugs a bit everywhere.
  • lmandel: This is cool, but it seems a bit busted.
  • miketaylr: There are a few bugs to fix. File bugs.
  • lawrence: you could make languages radio buttons rather than checkboxes.
  • brad: It would make more sense to be an OR.

BIG APPLAUSE AND CHEERS.

tshirt (mike)

Ticket is closed as FIXED. We need to pick colors and order some shirts/stickers.

  • mike: It was our compromised design. The raw assets are attached to the bugs.
  • karl: The assets are in Illustrator.
  • lawrence: We could get someone to convert the format for you, what would be a good format?
  • karl: It probably doesn't matter.
  • alexa: I can export it to SVG.
  • karl: Please.
  • mike: colors are not that important. But what do we do next?
  • lmandel: we just ask John for the ordering, who would know.
  • TODO: lmandel will ask john about t-shirt ordering for web compatibility.

WebCompat.com (alexa)

  • next steps, next iteration
  • alexa: I started working with some visual design and themes for web compatibility. The first thing that comes to mind is different browser logos, which is common but not very interesting. I started thinking about themes like progress, common goals, tension, etc. I did some style themes.

<https://github.com/webcompat/webcompat.com/wiki/Visual-Design-1st-iteration>

  • Theme: Light
  • Theme: Tension
  • Theme: Progress
  • alexa: I did another pass of the wireframes.
  • brad: There's two aspects to the bug reporting. Buys Ahoy, for people wanting to come in and contribute (by looking at existing bugs). And filing issues/bugs on the web. We probably want to keep those sep as they're different audiences.
  • alexa: We need to explore Github issues and tags, to make sure the right information is displayed.
  • alexa: I need to know how important you guys think these fields are and how we would map these to github API.
  • karl: You have the section for the URL, and later in the description one of the steps is go to URL, etc. We could be smarter here.
  • brad: That makes sense, as you type the URL fill in the description part, etc.
  • hallvord: The URL field is very important, but normal users aren't used to dealing with them.
  • brad: You could do a bookmarklet.
  • hallvord: Or an extension.
  • lawrence: The site design is simple, which I think is really good. We've been trying to find the focus for this site. Focus as shown is on Web users. I think we can have a link for a developer specific view as well.
  • alexa: I was thinking that this is for developers. Tell me what you think is missing for a development audience.
  • hallvord: One thing that could be interesting is: I'm a dev for this site. What are the problems.
  • brad: You could be able to sign up as an owner for a site (and get emails each time a bug is filed)
  • hallvord: That's an extreme niche of an audience, but very interesting and powerful. Search by website, domain name, pull in bugs from Chromium, WebKit, our list, etc.
  • lawrence: You have a problem with a site, you have nowhere to report it, here's a place. It's going to be a more technical site to begin with, but it would be good to make it as simple as possible. I think your designs are pretty welcoming.
  • alexa: for the web developer, the primary use case is about tracking your own Web site.
  • mike: not sure it is theprimary use case.
  • lmandel: for a user, it will be I want to report a bug and get it fixed. For a developer, it would be to track the bugs for my own sites.
  • mike: it will be still useful to report bugs about browsers.
  • hallvord: we would love to have these bugs in Bugzilla not necessary here. We would need probably a way to clone bugs.
  • brad: we could have form to report bugs on other bug systems.

(missed things - disconnected)

  • alexa: who are the primary people reporting things in Bugzilla?
  • brad: probably Mozilla employees are the number 1 audience.
  • karl: the UI is not very friendly. Even for web developers, some of them are not likely to report bugs. The UI is bad, and they don't want to have to open an account for each browser tracker.
  • alexa: for the next steps. What do you want?
  • mike: we should keep the bugs outside of bugzilla.
  • lmandel: we will figure out to report in othe bug systems.
  • hallvors: does that mean we need a github account?
  • mike: yes.
  • alexa: we can add a math problem.
  • lmandel: let's do that when we have this issue.
  • alexa: does this form cover what someone needs?
  • brad: it covers the basics.
  • hallvord: Another spam/privacy issue: is it possible to make some metadata non-public?
  • brad: The email field should only be there if you're not logged into github, etc.

(oops)

  • mike: oops2
  • lmandel: what is the purpose of trending bugs?
  • alexa: get the page more dynamic. And it helps people to get an understanding when they fall on this page.
  • brad: even if trending bugs just tracks which bugs have activity, it will at least show people that it's not a dead site.
  • alexa: my roommate also suggested some notion of preferences to only show iOS bugs, etc. She said one of the main things I want to know is "did I screw up, or is this a problem".

mike_s: It seems like a lot of bugs I've seen listed are the same bug over and over again (ua sniffing, viewport, non-mobile site). The idea that these are site-specific bugs, or even browser specific bugs can be misleading. It seems like you should be able to just push a button to describe a common bug.

  • brad: you could have classification of bugs in that interface. tick the box that this looks like a sniffing bug, or a viewport bug.

mike_s: if nothing else, it would make it easier to enter them. save time and clarify them.

  • alexa: get involved. How?
  • brad: a couple ways. 1) report bugs 2) to do some bugs ahoy (triage, investigation) work 3) doing outreach to sites. 4) adding content to the site, but we're probably not there yet.
  • alexa: so this get involved form, if i submit this form do i get kicked over to bugs ahoy?
  • alexa: I feel like if we just punt them over to bugs ahoy (or wherever), we risk losing them. It would be nice to maybe retain them in tagged lists so we can remind them to participate every few weeks.
  • brad: I think there's a general gut reaction against nagging people. In previous things we've let people browse, and if they're interested they pick up stuff. Anything we can do to increase participation is obviously good.
  • karl: it's not so much Join Us, but be part of our group--not Mozilla, but people who care about the web.

(people liked the visual design) mike_s: Do we have the possibility to report the bug on mobile?

  • alexa: brad mentionned bookmarklet.

See for visual inspiration http://www.pinterest.com/calexity/compatibility/

  • mike: I'll send an email about design so Alexa can move forward exploring new ideas in a single style.


UA override (karl)

serbian, hungarian, etc. Shall we pursue UA override there? For which purpose? Do we really have devices in these markets? (send mail to the list)

Web Opener Role Description (lawrence)

  • Any further suggestions? Post? Do we need other prep?

http://lawrencemandel.com/?p=4159&shareadraft=530bb55d5b77e

  • lawrence: it would be good to get some more feedback on this description.
  • karl: deadline?
  • lawrence: having a discussion by next week would be cool.


Topic: Broken Voices of the Web

Check the Planet Web Compatibility for the community news. Here a few posts lately published.

Topic: Web Compatibility Progress

FIXED (no DUPLICATE)

NEW

Tracked Actions

ONGOING

(move the DONE action items below and add the string DONE and possibly link to the record)

  • TODO-20130805-02: hallvord to test in bulk if Web sites are still working with a device information into the UA string Firefox OS. (Bug 901039)

DONE

Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Mobile/2014-02-24&oldid=939967"