101865 - Add basic support for mobile and tablet devices

Status: NEW

(bugzilla.mozilla.org :: User Interface, enhancement, P2)

Description

[Jim Salter]

With the improvement of web browsers for PDAs, it's very useful for me to take
my iPAQ around to meetings and use it for reporting on bugs and such to folks
over the wireless links.  Unfortunately, the main pages for my account default
to a large number of columns.  And even limiting the number of columns still
makes it difficult to read because of the size.

It would be nice to have either a switch (e.g. getNavType() == PDAExplorer) or a
preference available so that it would do a PDA browser version of the bugzilla
interface.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

Templates can be useful in the implementation of this enhancement (see bug 86168).

Comment 2

[Jim Salter]

Agreed - templates would be quite nice to have.  Likewise, the ability to 
switch between templates would be nice.  For example, a Blackberry RIM device 
is even smaller and simpler in the browser than the iPAQ Internet Explorer, and 
mobile cell phone browsers smaller still (which my company works on).

So the ability to templatize different versions would be great.

Comment 3

[GavinS]

see also bug#109545

Comment 4

[Dave Miller [:justdave]]

The User Interface component now belongs to Gerv.  Reassigning all UNCONFIRMED
and NEW (but not ASSIGNED) bugs currently owned by Myk (the previous component
owner) to Gerv.

Comment 5

[Dave Miller [:justdave]]

Reassigning back to Myk.  That stuff about Gerv taking over the User Interface
component turned out to be short-lived.  Please pardon our confusion, and I'm
very sorry about the spam.

Comment 7

[timeless]

Hrm, can you possibly provide some more details about what you actually want? (I work on a tablet device, we prototyped our work on iPAQs)

Specifically, do you want to see less content, or just have a format where things that are currently spanning too many columns get wrapped:

A B C D E F
=>

A B C
D E F

||

A D F
(with no sign of BCE).

Also, what dimensions/font sizes are you expecting, and about how many characters will this translate too? (my device is 800x480, I'm sure the iPAQ is narrower, so it is appreciated if *someone* provided answers to these questions).

Also, which pages/actions do you visit/take. Are you likely to report bugs using the same values? (have you used the bookmarkable template feature?) Do you frequently try to make the same changes to multiple bugs? (would the ability to record a change and then play it against another bug be helpful?)

Comment 8

[Frédéric Buclin]

Too late for 3.2.

Comment 11

[Paul [pwd]]

Can we make this a priority with us being so far along in the development of the mobile and tablet versions?

Comment 12

[Guy Pyrzak]

I haven't seen anything about YUI's mobile version being available yet. Let us know when it is available for use and we'll check it out.

Comment 14

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

Comment 16

[Paul [pwd]]

Any chance of renaming this to something more relevant to searches? Especially considering PDAs are by and large dead technology.

Comment 17

[Karl Dubost💡 :karlcow]

Currently this is becoming a bigger issue. 

First User test:
0. With Firefox OS on a ZTE device.
1. Accessing https://bugzilla.mozilla.org/
2. Receiving the login page for Bugzilla with the classic skin.
   It's not pretty but it's kind of usable for reading the content.
   EXCEPT for the login/password fields
3. pinch out the page to make the login/passwd fiels readable and usable
4. Entering the information
5. double tap for zooming out and getting the log in button
6. click the login button
7. Trying to select NEW
8. Fonts and text are not really usable. Too Small.


# Why is it an issue?

Because we are having Mobile products such as Firefox OS and Firefox for Android. Users will report bugs on the go if/when they need to. Even for a skilled person, currently the UI is not really usable, which makes it hard to have meaningful information. The issue is more acute in the case of the Mobile Web Compatibility activity.
https://wiki.mozilla.org/Compatibility/Mobile

We plan to provide a form for helping us to identify sites which are not behaving well with Mobile devices. See https://bugzilla.mozilla.org/show_bug.cgi?id=904713

It would be timely with Firefox OS being released on new markets to have a proper way of addressing the UI issue. We should maybe bump the priority for this one.

Comment 18

[Gervase Markham [:gerv]]

Historically, we have pointed people giving feedback from mobile devices at things like input.mozilla.org. But perhaps for web compat bugs that doesn't make as much sense.

Note that we are soon switching to the "Mozilla" skin as default, so you should test that for mobile compatibility rather than the current default skin.

Gerv

Comment 19

[Paul [pwd]]

it's ludicrous that a web browser organisation can't muster a responsive design and yet would like people to employ its web technologies.

Comment 20

[Andre Klapper]

The Bugzilla developers are not a web browser organisation, and nobody asked you to deploy anything hosted on mozilla.org. 
Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html before adding further comments. Thanks.

Comment 21

[David Lawrence [:dkl]]

(In reply to Gervase Markham [:gerv] from comment #18)
> Note that we are soon switching to the "Mozilla" skin as default, so you
> should test that for mobile compatibility rather than the current default
> skin.

The new Mozilla skin will only minimally help with viewing bugs on small screen sizes. Bugzilla really needs a complete rewrite of the HMTL of the different pages to make it truly responsive. This should be a hard requirement of the new UI being discussed as part of bug 662605.


(In reply to Paul [sabret00the] from comment #19)
> it's ludicrous that a web browser organisation can't muster a responsive
> design and yet would like people to employ its web technologies.

As stated, Bugzilla is not a product of Mozilla and is just used by Mozilla like any other external tool. The upstream Bugzilla community do have plans to enhance the UI and may be aided in part by Mozilla contributors but it will depend on available time and resources.

dkl

Comment 22

[Karl Dubost💡 :karlcow]

I just realized that the scope of this bug is quite huge "Bug 101865 - provide support for small devices (PDAs, Mobile, Tablets, etc.)".

If we break down into smaller pieces would that help. This afternoon I was playing with the current sandstone stylesheet for exploring if I could make an add-on that would reduce the information contained in the layout. At the same time, I was making the CSS more responsive. 

Many rules were based on the structure of the initial markup. Things like

#bz_show_bug_column_1 tr:nth-child(11)  {background-color: #eee;} 
#bz_show_bug_column_1 tr:nth-child(5) th {text-align:left; } 
#bz_show_bug_column_1 tr:nth-child(5) td {padding:0} 

It's not very good but very likely to break to any changes of the template. :) When inspecting the markup I realized that many hooks (mostly id and class) for making it easier to create new CSS. It's when I started to think that maybe it would be good to break down all of this in more steps (== bugs).

1. New markup templates for the bug page
2. New CSS template for the bug page
3. etc. (input, search, etc.) 

Solving them one by one until everything is mobified and/or easier to modify through add-ons.

Comment 23

[Frédéric Buclin]

(In reply to Karl Dubost :karlcow from comment #22)
> #bz_show_bug_column_1 tr:nth-child(5) td {padding:0} 
> 
> It's not very good but very likely to break to any changes of the template.

These rules are bmo-specific.


> :) When inspecting the markup I realized that many hooks (mostly id and
> class) for making it easier to create new CSS.

bmo runs Bugzilla 4.2.7. You would have to look at Bugzilla 4.5.2 for such considerations as there have been many changes when we moved to HTML5.

Comment 24

[Karl Dubost💡 :karlcow]

(In reply to Frédéric Buclin from comment #23)
> These rules are bmo-specific.

yes. I understand the bug is about bugzilla as large, but I was wondering what would have been the most effective way. Fix for bmo, and push up if working or the opposite but with a much longer deadline.

> bmo runs Bugzilla 4.2.7. You would have to look at Bugzilla 4.5.2 for such
> considerations as there have been many changes when we moved to HTML5.

we = bmo?
we = bugzilla?

Comment 25

[David Lawrence [:dkl]]

(In reply to Karl Dubost :karlcow from comment #24)
> (In reply to Frédéric Buclin from comment #23)
> > These rules are bmo-specific.
> 
> yes. I understand the bug is about bugzilla as large, but I was wondering
> what would have been the most effective way. Fix for bmo, and push up if
> working or the opposite but with a much longer deadline.
> 
> > bmo runs Bugzilla 4.2.7. You would have to look at Bugzilla 4.5.2 for such
> > considerations as there have been many changes when we moved to HTML5.
> 
> we = bmo?
> we = bugzilla?

BMO is something between 4.2.7 and 4.5.2 as we backport most things as we deem appropriate such as
comment tags, performance improvements, REST API, etc. But I agree this type of work should start
with the upstream as a base and not the code BMO is using. BMO will pick it up eventually. As for
the Mozilla skin, once of our goals is to take the good parts and work it upstream as a general
skin called Sandstone without any Mozilla branding. If you want to take some of the BMO skin
and start that task as part of this then that would be great,

dkl

Comment 26

[Frédéric Buclin]

(In reply to Karl Dubost :karlcow from comment #24)
> we = bmo?
> we = bugzilla?

This bug is filed in the Bugzilla product, so we = the Bugzilla team, not the bmo team.

Comment 31

[Denis Roy]

(In reply to David Lawrence [:dkl] from comment #21)
> Bugzilla really needs a complete rewrite of the HMTL of the
> different pages to make it truly responsive. This should be a hard
> requirement of the new UI being discussed as part of bug 662605.

Agreed with Karl Dubost ... The entire bugzilla doesn't need to be responsive all at once.  I'm sure users would appreciate having only these three pages responsive:

Bugzilla Home/landing page so one can log in
Search page so one can search
show_bug page so one can view/edit bugs

If the bugzilla team agrees that the above would be a good start, Eclipse is willing to invest time in making it happen and supplying a Git patch.

Comment 32

[Gervase Markham [:gerv]]

Denis: that's a very kind offer :-) I agree it would indeed be a good start. glob <[e-mail]> is working on some prototypes for show_bug in Q1 2015 which are supposed to be more mobile-friendly; you should coordinate with him.

Gerv

Comment 33

[Denis Roy]

Our crack team of web developers have received links to this bug. I see glob is CC'd too so I consider us to be "in touch".

Glob: can you post a URL to the git repos for these UI prototypes?  We can then apply them to a head install of Bugzilla and start chipping away at it.  Has the bugzilla team agreed on the usage of a framework, such as bootstrap?  I remember seeing some discussion about it but I'm unsure of the status.

Comment 34

[David Lawrence [:dkl]]

(In reply to Denis Roy from comment #33)
> Has the bugzilla team agreed on the usage of a framework, such as bootstrap?
> I remember seeing some discussion about it but I'm unsure of the status.

It was decided to go with jQuery as the framework and initial support has been added to trunk for any new projects to use. YUI2 is still available but will be deprecated once everything is converted over.

http://git.mozilla.org/?p=bugzilla/bugzilla.git;a=commit;h=a50e8fd42e682ac115792677104a467445a1c0ad [github]

dkl

Comment 35

[Mark Côté [:mcote]]

Yeah, the decision thus far only concerns the the core JS library, which we're switching from YUI to jQuery.  Bugzilla currently doesn't use a real CSS framework, so that's a separate concern.  But I would support experimentation with something like bootstrap (I'm actually playing with an alternate, simplified, Bootstrap-based bug view myself, but as a separate, third-party client-side app using the REST API).

Glob says he will have some blog posts up about his new designs next week.

Finally, note that one of the most annoying things for responsive design is the fact that we use monospace, <pre>-formatted text in the comments.  Many existing comments, in BMO at least, rely on the fact that this formatting is always applied.  Once Markdown support in comments is fully finished, though, I think expectations will change, so I would personally label Markdown support as a blocker for true responsive design.  There are a handful of outstanding bugs for it right now; the BMO team isn't actively working on any of them right now, so any help from other installations or individual contributors would be great!

Comment 36

[Denis Roy]

> Bugzilla currently doesn't use a real CSS framework, so that's a separate concern. 

I know our web guys would vouch for bootstrap, as we've had much success with it, but from what I understand, a CSS framework is not a blocker to making a responsive set of pages that would make BZ usable on devices.


> so I would personally label
> Markdown support as a blocker for true responsive design.

If a "true responsive design" is another bug, that would be great. While we certainly don't want to put something together half-baked, we would like to ease this specific pain point rather rapidly without committing to changing the world.

My initial thinking, and this is perhaps naive, is that we can make a "mobile" template and CSS that would do most of what we want. At any rate, the mobile template would offer better usability on devices than status quo.

Comment 37

[Gervase Markham [:gerv]]

(In reply to Mark Côté [:mcote] from comment #35)
> Finally, note that one of the most annoying things for responsive design is
> the fact that we use monospace, <pre>-formatted text in the comments.  Many
> existing comments, in BMO at least, rely on the fact that this formatting is
> always applied.  Once Markdown support in comments is fully finished,
> though, I think expectations will change

Markdown doesn't solve the legacy problem... but anyway, the whitespace behaviour can now be changed with CSS, so it would be fine for a mobile UI to default to wrapping the text, and have a button or toggle to set it back to <pre>-style if someone was trying to interpret a comment which relied on it.

Gerv

Comment 38

[Karl Dubost💡 :karlcow]

For markdown, a soft way to take into account the legacy is to match the tag "mdown" on specific comment.
See for example https://bugzilla.mozilla.org/show_bug.cgi?id=827626#c7 

> the whitespace behaviour can now be changed with CSS, so it would be fine for a mobile UI to default to wrapping the text

Yes.

I Agree with Denis Roy, that an attempt at small steps would be better and would not jeopardize a big rewrite. It could even help understand what should be done for the big rewrite by exhibiting some UX and layout issues.

Comment 39

[Mark Côté [:mcote]]

(In reply to Denis Roy from comment #36)
> > Bugzilla currently doesn't use a real CSS framework, so that's a separate concern. 
> 
> I know our web guys would vouch for bootstrap, as we've had much success
> with it, but from what I understand, a CSS framework is not a blocker to
> making a responsive set of pages that would make BZ usable on devices.

Yup, that's what I was trying to say. :)  I also agree that Bootstrap is very nice to work with.

> > so I would personally label
> > Markdown support as a blocker for true responsive design.
> 
> If a "true responsive design" is another bug, that would be great. While we
> certainly don't want to put something together half-baked, we would like to
> ease this specific pain point rather rapidly without committing to changing
> the world.
> 
> My initial thinking, and this is perhaps naive, is that we can make a
> "mobile" template and CSS that would do most of what we want. At any rate,
> the mobile template would offer better usability on devices than status quo.

Sure, I was stating my understanding of what one of the BMO devs told me, but if you think you can create a useful mobile UI without a lot of yak shaving, I fully support the attempt. :)

Comment 40

[Denis Roy]

(In reply to Mark Côté [:mcote] from comment #35)
> Glob says he will have some blog posts up about his new designs next week.

Did I miss those?  It would be great to use this bug to coordinate our efforts in helping resolve this issue  :)

Comment 41

[Mark Côté [:mcote]]

(In reply to Denis Roy from comment #40)
> (In reply to Mark Côté [:mcote] from comment #35)
> > Glob says he will have some blog posts up about his new designs next week.
> 
> Did I miss those?  It would be great to use this bug to coordinate our
> efforts in helping resolve this issue  :)

It was more like two weeks, but here's his first post on the topic: https://globau.wordpress.com/2015/01/08/changing-the-face-of-bugzilla-mozilla-org/

His posts are also syndicated to http://planet.bugzilla.org/, as are other core Bugzilla contributors', including mine (well, actually, mine aren't, but that's due to a bug that I'm fixing now. :)

Comment 42

[Denis Roy]

The blog post mentions changing the face of the BMO UX, whereas this bug is about supporting "small devices".  I'm not sure how much of BMO's work makes it into Bugzilla, but Glob's work seems to be very complex, examining groups and people to determine which fields to show, whereas the work we'd do would mainly be in CSS (ie, determining which visual elements to display based on available screen width) to make the most common mobile use-cases more tolerable.

I think we'll produce a working prototype of a mobile-friendly skin/theme for the bugzilla team to try. If you think it can be useful, we can continue, if not, we can chalk it up as an experiment.

Comment 43

[Mark Côté [:mcote]]

His work, as I understand it, also involves building a framework to make adding new bug views easier.  I think it'll be upstreamed; generally any fixes and improvements to BMO that aren't too Mozilla-work-flow-specific get put into core Bugzilla.

But yeah, if you are just going for a skin, you wouldn't need it.  Definitely worth a shot!

Comment 44

[Edouard Poitras]

Attachment: duskmobile_screenshots.tar.gz

Here's a start - a DuskMobile skin (based on Dusk) along with a few template changes.
The results (new vs current) are displayed in the screenshots attached with this post.

The following pages were worked on:
Home
New
Search
Browse
Viewing Bug

Templates:
A few modifications to the templates needed to be done - mostly adding classes and a few instances of converting tables to divs.
I found the table-centric HTML structure very restrictive when making the pages mobile-friendly.  I suspect that eventually, a whole rewrite of the HTML would need to happen to get rid of all the table markup.

Skin:
I implemented a very simple grid system that was satisfactory for the pages mentioned.

I did only minimal testing with custom fields; this will have to be tested thoroughly.

Comment 45

[Edouard Poitras]

Attachment: duskmobile.tar.gz

You can also try it out by extracting duskmobile.tar.gz in your bugzilla directory.

Note that extracting duskmobile.tar.gz will add a DuskMobile skin to your bugzilla instance, but it will also add custom templates in templates/en/custom.  These templates are globally overriden (they effect your other skins) so you may want to remove them once you're done testing.  However, you should see no changes from the default templates (if you do, it's a bug).

Comment 46

[Denis Roy]

Hmmm. Perhaps the screenshots were too much?

We've formatted the contribution as a new skin to allow you to flip between Dusk and DuskMobile.  We will happily provide a git patch against the default templates and CSS if that is what you'd prefer.

Our goal was to provide no discernible difference at full screen width, but remove some UI elements when the window was narrowed to tablet/phone size.

Please let us know if you'd prefer a git patch and we'll make it happen.

Comment 47

[Mark Côté [:mcote]]

These looks really nice!  One of the BMO devs will take a look soon, but yeah, a git patch is probably best; easier to review.

Comment 48

[KitchM]

"Attachment is not viewable in your browser because its MIME type (application/gzip) is not one that your browser is able to display."

Isn't that just great!  And I'm using Firefox 35.0.1.

Comment 49

[Gervase Markham [:gerv]]

(In reply to KitchM from comment #48)
> "Attachment is not viewable in your browser because its MIME type
> (application/gzip) is not one that your browser is able to display."
> 
> Isn't that just great!  And I'm using Firefox 35.0.1.

What do you expect? Browsers can't view gzip archives. Click the "Download the attachment" link directly below the text you quote.

Gerv

Comment 50

[KitchM]

Your's is an interesting question.  I quess the obvious answer would be to say that I expect things to work as implied.

If I select to view the details, I would expect to see them.

Further, other forum software allows the viewing of attachemts.  What happened in this case?

Actually, I'm very surprised I would have to explain that.

Comment 51

[Edouard Poitras]

Attachment: duskmobile-4.4.7.patch

A git patch of DuskMobile that can be applied to Bugzilla 4.4

Comment 52

[Edouard Poitras]

Attachment: duskmobile-5.1.patch

A git patch of DuskMobile that can be applied to Bugzilla's master branch as of Feb. 17th, 2015 (5.1)

For this one I couldn't get the different stylesheets to be imported properly so I dumped all of DuskMobile's CSS into it's global.css file.  This is temporary until I investigate further.

Comment 53

[Frédéric Buclin]

(In reply to Edouard Poitras from comment #52)
> For this one I couldn't get the different stylesheets to be imported properly

In 5.x, Bugzilla only uses 4 CSS files: admin.css, bug.css, buglist.css and global.css. All other CSS files will be ignored.

Comment 57

[JT Moree]

Can I ask for a status update on this bug?  Given the number of duplicates it seems like a requested feature and the comments suggest that the work and patches have been done and redone.  Why is this not pulled upstream into a release?

Are there concerns with the patches?  Is everyone just too busy to review?  Is there a UX redesign in the works which makes this obsolete?  If so, is there an ETA for than landing?

Comment 58

[bug.zilla]

The stock browser on my LG G3, compresses the columns to show a "mobile" friendly page.

There's still empty space if you deliberately scroll to the right (but you don't have to since one only has to scroll up and down).

It's definitely more user friendly.

Comment 59

[Kohei Yoshino [:kohei]]

I’ll work on this in this Q2 in hope that the basic optimization will be included in BMO-based Bugzilla 6.0.

Comment 68

[Alberto Fabbri]

Is this ever going to happen? Using Bugzilla on a mobile browser is a really frustrating experience.

Comment 70

[Jack]

Hi, am I missing something that this 23year old bug is still open and prevalent as a dysfunctional UX (User eXperience) issue? Have others implemented private CSS fixes for this enduring issue? If so, I'd love if you shared.

Essentially: 'Bugzilla does not display correctly on screens smaller than desktops.
I would have posted earlier, but it was such a nuisance!

As @Denis Roy said, 10 years ago in comment #31

Agreed with Karl Dubost ... The entire bugzilla doesn't need to be
responsive all at once. I'm sure users would appreciate having only these
three pages responsive:

Bugzilla Home/landing page so one can log in
Search page so one can search
show_bug page so one can view/edit bugs

If the bugzilla team agrees that the above would be a good start, Eclipse is
willing to invest time in making it happen and supplying a Git patch.

Comment 71

[KitchM]

Isn't this a simple issue of the web page not being compliant with the W3C?

Comment 72

[Dave Miller [:justdave]]

(In reply to KitchM from comment #71)

Isn't this a simple issue of the web page not being compliant with the W3C?

No, it's an issue of the data not being structured in a way that makes it able to be rearranged to make best use of the space.

Comment 73

[KitchM]

I guess I'm confused then. Is the OP wanting the information to flow from some place on the 'Net that is not a web page?

Comment 74

[Kagami Rosylight [:saschanaz] (they/them)]

This is about having mobile-device-friendly page layout, and we recently got some good progress e.g. in bug 1878813.

Comment 75

[KitchM]

I assume you mean "web" page layout, which was exactly what I was trying to point out. The information from web pages is laid out by web site designers. If they do not conform to the standards setting body, the information will not display properly on all devices. Further, we will never get information the way we want if the browser on our device does not comply either. This is the whole point of having standards.

On the other hand, if a person feels that the standards do not allow for the device/browser combination being used, one must raise the issue with the W3C. This is the correct place to force changes upon those who create web sites. (At least with those who know what they're doing. You can lead a horse to water........)