Open Bug 130835 Opened 22 years ago Updated 9 months ago

Make Bugzilla's index.cgi (home page) useful for logged-in users

Categories

(Bugzilla :: User Interface, enhancement, P1)

Product:
Bugzilla
Component:
User Interface
Type:
enhancement

Tracking

()

People

(Reporter: mpt, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: ue, Whiteboard: [roadmap: 4.2])

Attachments

(7 files, 14 obsolete files)

Placeholder Bugzilla graphic
1.63 KB, image/gif
Details
Mockup version 6
18.18 KB, text/html
Details
Simple CSS for page layout
2.49 KB, text/plain
Details
tm's mockup #1
22.91 KB, text/html
Details
second attempt incorporating suggestions
26.68 KB, text/html
Details
v4
17.02 KB, patch
mkanat
: review-
Details | Diff | Splinter Review
Bugzilla_Home_2002.jpg
305.02 KB, image/jpeg
Details 
The problem
-----------
Bugzilla is too inefficient to use. It's difficult to get from one area (e.g. 
Search for bugs) to another (e.g. File a bug); in part this is because of *too 
many* links from one to the other, and in part it's because the links are in 
inconsistent positions. Bugs often go for months or (in some cases) years 
without being triaged or verified. Duplicate bugs can coexist for months 
without being marked as such. Bugzilla's front page gives very little idea of 
the number or variety of reported bugs.

The solution
------------
Redesign the front page.
*   Introduce tab navigation (Home, Search, File a bug, Reports, Preferences,
    Log In/Log Out) which will eventually be applied to all Bugzilla pages.
*   Feature a simple search form in the middle of the page.
*   Display hourly updated lists of bugs which need attention:
    -   the n oldest unconfirmed bugs
    -   n random unresolved bugs (for exposing duplicates and piquing interest)
    -   the n bugs with the oldest unreviewed patches
    -   the n oldest resolved but unverified bugs.
    A good value of n seems to be 8.
*   Display hourly updated Bugzilla statistics:
    -   total number of bugs filed, resolved, and open
    -   number of bugs filed, reopened, resolved, and fixed in the last 7 days
    -   number of bugs filed, reopened, resolved, and fixed in the last 24
        hours.

How the back end will work
--------------------------
index.cgi keeps a record of when the front page was last updated. When it has 
finished rendering the HTML, it checks the current time against the last update 
time. If the hour is different (e.g. if the last update was at 12:03 and it is 
now 13:01), it triggers an update of buglists and bug counts which appear on 
the front page. This update should not lock simultaneous attempts to run 
index.cgi.
>*   Introduce tab navigation (Home, Search, File a bug, Reports, Preferences,
>    Log In/Log Out) which will eventually be applied to all Bugzilla pages.

Interesting proposal, but assuming that these tabs are dynamic in any sense (per
installation, per user, etc.), this would probably require CGIs for all content,
which should push it back to after templatization work, likely Bugzilla 2.20 at
the earliest.

>*   Display hourly updated lists of bugs which need attention:
>    -   the n oldest unconfirmed bugs
>    -   n random unresolved bugs (for exposing duplicates and piquing interest)
>    -   the n bugs with the oldest unreviewed patches
>    -   the n oldest resolved but unverified bugs.
>    A good value of n seems to be 8.

This sounds like a good idea for the front page (index.cgi), but the actual
queries included and the timing should be on a per installation basis.  Random
bugs is bug 68357.

>*   Display hourly updated Bugzilla statistics:
>    -   total number of bugs filed, resolved, and open
>    -   number of bugs filed, reopened, resolved, and fixed in the last 7 days
>    -   number of bugs filed, reopened, resolved, and fixed in the last 24
>        hours.

Again this should probably be somewhat configurable (which reports are included
and the time values).  Fixed references (this month and this quarter) might also
be important for some users.  Add verified and/or closed statuses to your list
as well.  Past n days will require fixing bug 77280 and bug 37749.  The fixed
numbers can be somewhat misleading though, and it might be nice to have a format
like "9995 (+1000/-5) bugs FIXED".

>index.cgi keeps a record of when the front page was last updated. When it has 
>finished rendering the HTML, it checks the current time against the last update 
>time. If the hour is different (e.g. if the last update was at 12:03 and it is 
>now 13:01), it triggers an update of buglists and bug counts which appear on 
>the front page. This update should not lock simultaneous attempts to run 
>index.cgi.

IMHO, this should only be done if the user requests it, or should be left to the
browser.  I've already seen an RFE to let Moz reload every X minutes, and this
wouldn't spike traffic on the hour.

If we try to avoid spiking traffic by letting the server do this once for all
sessions, it won't work for the lists of unconfirms, unresolved, etc. bugs you
propose because only those n would show up during any given hour.  In the event
that all (or most) n are confirmed, triaged, etc. within the hour, the list
would then be useless (or mostly so) for the rest of the hour.  rkaa could
probably knock off 50% of them in 4 or 5 minutes! :-)
Depends on: 37749, 68357, 77280
> assuming that these tabs are dynamic in any sense

No, they're not dynamic in any sense. They differ slightly depending on whether 
the page is being viewed by a logged-in user, but (almost) all Bugzilla pages 
behave that way already.

Most of the rest of your comments are of the form `the feature should be 
customizable before it exists' ...

> IMHO, this should only be done if the user requests it, or should be left to
> the browser.

No, it's nothing to do with either the user or the browser. Hooking it up to 
index.cgi is just a convenient way of avoiding the need to use cron for it.

> In the event that all (or most) n are confirmed, triaged, etc. within the
> hour, the list would then be useless (or mostly so) for the rest of the hour.

I know, but it's better than nothing, which is what we have now.
I'm in favour of implementing these changes, and I am requesting support from
the reviewers to start hacking on them. If reviewers have issues with some of
the points, please post explaining which ones should be changed.

mpt: it would be great if you could attach your HTML file so we could have an
example and code to start off with.

> Most of the rest of your comments are of the form `the feature should be 
> customizable before it exists' ...

I agree completely; let's get it done first.


I'd like to see, and be able to discuss, a mock-up before anyone writes any code
:-) 

It would be nice also to think about how we can do this in such a way that
someone who doesn't want the stuff on the front page doesn't have to run the
queries. I have ideas about that which I need to write up.

Gerv
Any mockups should somehow make the link to the bug reporting instructions
more visible (currently it is too well hidden in a visual sense).

No, I don't really have an idea for the front page, but it's something
that should be considered, even if it only helps the UNCO flood a little
mpt has a mockup that he will, in due time, produce (i hope).

Gerv: regarding the "queries" part, the content of the page would be cached and
regenerated at a fixed time interval (mpt's explanation covers this, removing
the need for a cronjob with a self-checking generator triggered on page load),
so it wouldn't be slow or anything. 

You mean the user wouldn't want to _see_ that at all, even at no additional cost?
Attached file Mockup of new Bugzilla front page (obsolete) — 
Various points:
1.  Since I designed the current Bugzilla front page in 1999 (mainly
rearranging
    deckchairs), attempts to improve Bugzilla's UI have followed the usual
    open-source pattern of piling more and more stuff in -- navigation, links
to
    help pages, etc -- rather than removing stuff. Since speed of finding
    something is inversely proportional to the number of choices, and since
    Nobody Reads The Help, I think this has made Bugzilla *harder* to use. So,
    before complaining that the new design reduces the amount of text devoted
to
    {whatever}, please consider that you might be missing the point. (Google
    doesn't have a Help link on its front page *at all*.) For example, John
    Levon's `Any mockups should somehow make the link to the bug reporting
    instructions more visible': what on earth is such a link doing on the front

    page at all? No wonder people can't find it -- it should be at the top of
    the `File a bug' page, as should the links to the Bugzilla Helper and the
    bugs filed today.
2.  The CSS needs to be separated out into its own file, which should be the
    basis of a Bugzilla-wide style sheet (since the tabs should be at the top
    of every page).
3.  In MSIE 5.0 for Windows (don't know about 5.5 or 6.0), the words `File a
    bug' sometimes separate onto three lines for no apparent reason. If you
    consider this important enough to work around, change it to
    File a bug.
4.  In MSIE 5.x for Mac OS, the columns of bugs are vertically centered instead

    of aligned along the top. If you consider this important enough to work
    around, change the doctype from Strict to 4.01 Transitional, and add
    valign="top" to the TR element.
5.  The `Unreviewed' column in this screenshot is only narrow in this mockup
    because one of the other columns contains some very long filenames. Usually

    this won't be the case.
You're correct about the reporting guidelines (also see somewhat
related bug 140617, which is another sensible place to have it IMO).

I'm a bit unsure of the tab-style interface though. It confuses
actions ("log out", "file a bug") with switching between screens
("preferences", "home"). I'm sure I don't need to tell you about
the iarchitect tab examples, so can you justify your decisions here
a little more ? Why can't the actions be buttons ?

Also, this is possibly just me, but I have to admit to being confused
at to what the columns of bugs actually are for. Is this what a new user
will see with default preferences ?

(If I'm just irritating you all, just say)
Where is the list of "recent bugs" ? Where is the list of "top bugs" ?
This is IMHO what a normal bugzilla user is most interested in. Heavy
users like the developers and triagers can

a) change some prefs or
b) use their stored queries
> It confuses actions ("log out", "file a bug") with switching between screens
> ("preferences", "home").
The only tab which has a direct action when clicked is the `Log Out' one; if it
would make you happier, you could change it to a page containing a `Log Out'
button. I don't think the marginal increase in correctness would be worth it.

> being confused at to what the columns of bugs actually are for.
See comment 0. Gradually, it will solve the problem of bugs/patches getting lost.

> Where is the list of "recent bugs" ? Where is the list of "top bugs" ?
See comment 7, point 1, last sentence.
> a page containing a `Log Out' button

I don't think sarcasm is productive (though it is amusing).

> See comment 7, point 1, last sentence.

So I have to click on "File a bug" to find my way to the bugs
today list. Counter-intuitive. (And yes, before you ask, people
do want to see this list for reasons other than filing a report).

> solve the problem of bugs/patches getting lost.

I did read this, you took my quote out of context. I still don't see
any clarification of what a user (as opposed to people
triaging/developing) will see, and I don't think this design will
help the Fear of Bugzilla problem.

But I'll shut up now, I'm clearly just irritating you and I think
my point has been made (and the mock up is an obvious improvement
over what is there now).
> You mean the user wouldn't want to _see_ that at all, even at no additional 
> cost?

As mpt will tell you, extra user interface "features" are not free in terms of
added complexity.

> solve the problem of bugs/patches getting lost.

This statement implies that there are Mozilla coders with lots of free time, who
just need reminding of Bug X to go off and fix it. I'm not convinced this is the
case.

So, to the design:

While almost anything would be an improvement on the current page, I don't think
this design achieves a goal of reduced complexity.

- What are the stats for? How exactly are they useful to anyone?
- "the n bugs with the oldest unreviewed patches" - I'm not convinced of the
value here. There are often good reasons why a patch has not been reviewed and
not been marked obsolete.
- "the n oldest resolved but unverified bugs." Again, there are occasionally
reasons why a bug is not verified. To keep it on the duplicates.cgi page, for one.

I'm also uneasy about the Log Out link being a tab. 

We also need to determine how much of this design is suitable for a general
Bugzilla front page, and how much (e.g. the breadcrumb navigation) should be in
bugzilla.mozilla.org's custom front page template.

Another point to note: this is not just a design for the front page. If we
implemented this, we would have to implement the tabbed interface on the other
four major CGIs at the same time, for consistency.

Gerv
John, there was no sarcasm. For example, both Slashdot (`Preferences' > `Log 
out') and Manila (`Sign Out' > `Sign Out') have two steps to log out.

> I don't think this design achieves a goal of reduced complexity.
That wasn't a goal. More obvious, yes. More efficient, yes. Less complex, no.

> > solve the problem of bugs/patches getting lost.
> This statement implies that there are Mozilla coders with lots of free time
No, it implies that bugs and patches often get lost. Free time is irrelevant.

> What are the stats for? How exactly are they useful to anyone?
Instant encouragement (150 fixed this week!), and conveying Bugzilla's scale.

> why a bug is not verified. To keep it on the duplicates.cgi page, for one.
That's a silly reason. Fix the design bug in duplicates.cgi (in a *separate* 
bug, not this one). You'll have *months* before this front page is affected.

> If we implemented this, we would have to implement the tabbed interface on
> the other four major CGIs at the same time, for consistency.
No, we wouldn't. The navigation between the home page and the other pages is 
completely inconsistent now, so this wouldn't make them any less consistent. We 
should add the tabs to the other CGIs later, but it shouldn't block this bug.

Before this bug report turns into a novel: (1) I'm much more interested in 
comments of the form `how about we improve the design by doing {x}' than 
comments of the form `the design isn't perfect because {y}', and (2) I'm much 
more likely to read such comments if they're sent to mpt@myrealbox.com than if 
they're posted to this bug. (CC to n.p.m.webtools, if you like.)
No longer depends on: 68357
> > I don't think this design achieves a goal of reduced complexity.
> That wasn't a goal. More obvious, yes. More efficient, yes. Less complex, no.

OK: I think this design contains unnecessary complexity.

> No, it implies that bugs and patches often get lost. 

I dispute your assertion that a list of unreviewed patches on the front page
will improve matters. (This is relevant to the bug; if the list is useless, we
shouldn't have it.) There may be other flaws in Bugzilla which make it easier
than it should be to lose patches, but I don't agree this will help.

> > What are the stats for? How exactly are they useful to anyone?
> Instant encouragement (150 fixed this week!), and conveying Bugzilla's scale.

Then I'd go for the simpler:

                 124559 bugs on file, 19841 open
    Last 24 hours: 120 bugs filed, 97 resolved (including 34 fixed)
    Last 7 days: 653 bugs filed, 487 resolved (including 119 fixed)
                 Numbers updated in the last hour

> That's a silly reason. Fix the design bug in duplicates.cgi (in a *separate* 
> bug, not this one). You'll have *months* before this front page is affected.

It's not a design flaw. Bugs need to stay on that page for an amount of time
after they are fixed so people with slightly old builds file less dupes.
Therefore, we thought it sensible to keep them there between being resolved and
verified. (Other sensible heuristic suggestions welcomed.) This made it easy to
control whether a bug was on there or not, so popular bugs could be left there
for longer than irrelevant ones. Or would you prefer yet another checkbox: "keep
on duplicates page"?

> The navigation between the home page and the other pages is 
> completely inconsistent now, so this wouldn't make them any less consistent.

I don't agree that it's completely inconsistent. Anyway, not having tabs on the
other pages breaks the whole tabs metaphor. That would certainly confuse me, as
a user.

Gerv
Guidelines for a graphic in this template: equal width and height, with the
substantial part of the graphic occupying the top left corner of the image, and
transparent background. A graphic sized 96*96 pixels (the substantial part
being 48*48 pixels) will have no jaggies at Mozilla's 16px default font size.
Attached file Mockup version 2 (obsolete) — 
This revision incorporates suggestions from John Levon, Ralph Mellor, and Sasha
Claus, and fixes other minor errors.
*   There's a usage hint underneath the Quick Search field.
*   The page is now valid XHTML 1.0.
*   Absolute dimensions have been abolished, so the page works perfectly with
    Text Zoom in Mozilla, and nearly perfectly with Text Zoom in MSIE for Mac.
    (It's still vulnerable to UAs with varying default margins for BODY etc,
    and Hixie might faint if he studied the CSS in detail.)
*   The tab CSS rules are more complete, in preparation for adding the tab
    navigation to the other Bugzilla pages.
*   The typography is more consistent (2~3 typefaces rather than 3~4).

> Then I'd go for the simpler:
What you suggest is very similar to what I had some months ago, but then I
realized that (a) having just the total count followed by the open count makes
it seem as if the latter is not a subset of the former, and (b) excluding
reopened counts would tend to encourage sloppy resolutions (to the extent that
the numbers will affect triage at all).

> (Other sensible heuristic suggestions welcomed.)
List bugs with at least {x} duplicates which have been fixed for fewer than {y}
months, irrespective of their verification status.
Attachment #84309 - Attachment is obsolete: true
>> The navigation between the home page and the other pages is 
>> completely inconsistent now, so this wouldn't make them any less consistent.
>
> I don't agree that it's completely inconsistent. Anyway, not having tabs on 
> the other pages breaks the whole tabs metaphor. That would certainly confuse 
> me, as a user.

Well, I think it's currently completely inconsistent, personally - nothing
relates inner pages to the front page, unless you want to count that it has
links (*wink*). But I do think that the design should apply to the whole of
bugzilla, so it's important that it be a good one. And yes, having it different
from the rest of bugzilla is no good, so as soon as we fix this, we should move
on to fixing the rest.

I agree on the general navigation design, though I'd nitpick that the
breadcrumbs have no place in most bugzilla installations and the logo is
bmo-specific. These are not major problems and wouldn't stop me from approving
the design. My users have a _very_ hard time navigating bugzilla, and just
showing one of the engineers the design for 5 minutes resulted in an "oh, now I
know where I am". 
I'm getting horizontal scrollbars on the mock-up using RC2 on Windows XP,
1024*768 display, 96dpi resolution and 16px proportional fonts.
Re attachment 84503 [details]:

There should be a link to create a bugzilla acccount.

> Numbers updated 2002-01-14 12:34 UTC 

This should be local time, like everything else in bugzilla.

> Last 7 days: 653 bugs filed, 22 reopened, 487 resolved including 119 fixed 
> Last 24 hours: 120 bugs filed, 6 reopened, 97 resolved including 34 fixed 

These should include links to a query to display the bugs.

I currently have a browser window use half of the screen width-wise and almost
the whole screen height-wise.  The design in the attachment makes the columns
very narrow in this case.  I suggest removing the bug numbers or putting them in
the same column as the short description to allow more width to be used by the
description.

Is this going to be optional?  I am not sure if I would want such a busy page
confronting me when I enter bugzilla.  Also, what are "bread crumbs"?
> What you suggest is very similar to what I had some months ago, but then I
> realized that (a) having just the total count followed by the open count makes
> it seem as if the latter is not a subset of the former, 

I assumed it wasn't. Are you saying that the 487 is a subset of the 653?

> and (b) excluding
> reopened counts would tend to encourage sloppy resolutions (to the extent that
> the numbers will affect triage at all).

I don't think they'd affect triage at all. People would not sloppily resolve
bugs just to see these numbers change. That would be irredeemably sad.

> > (Other sensible heuristic suggestions welcomed.)
> List bugs with at least {x} duplicates which have been fixed for fewer than 
> {y} months, irrespective of their verification status.

I don't think that would work. Some bugs are in milestones, so tend to have
dupes filed for far longer, whereas others only appear for a few days, and so
the number of dupes drops off quickly. Any heuristic of this form would either
remove the first sort too quickly, or have the second sort cluttering up the
place for too long.

> There should be a link to create a bugzilla acccount.

Presumably Log Out will become Log In, and Preferences could become Create
Account. These would lead to the same screen at the moment, but that's not a
problem.

I think the width problems can be solved by removing the Unreviewed column,
which I don't think will help.

Gerv
Attached file Mockup version 3 (obsolete) — 
> Are you saying that the 487 is a subset of the 653?
No, but the 104718 *is* a subset of the 124559. (This difference in meaning is
why the stats should *not* go in a table, as some have suggested.)

> Log Out will become Log In, and Preferences could become Create Account.
Exactly right. This mockup shows the tabs as they are when you're logged out.

The horizontal scrolling is the fault of the CSS for the breadcrumb strip and
the tabset, and I don't know why. (They overflow by the same amount no matter
how wide the window is). It's nothing to do with the buglists -- they fit in
the window width comfortably even at 640*480.
Attachment #84503 - Attachment is obsolete: true
Attached file Mockup version 4 (obsolete) — 
With Hixie's help, I eliminated the horizontal scrolling in Mozilla. (It still
scrolls in Mac IE, but that's a bug in Mac IE.)
Attached file Mockup version 4 (obsolete) — 
Must ... attach ... the correct ... file ...
Attachment #84766 - Attachment is obsolete: true
> No, but the 104718 *is* a subset of the 124559. (This difference in meaning is
> why the stats should *not* go in a table, as some have suggested.)

How does adding the "Resolved" numbers help with this confusion? How about:

124559 bugs filed, of which 104718 resolved, 19841 open 
Last 7 days: 653 bugs filed, 487 resolved including 119 fixed
...

I still think this section is a bad idea. When Request Tracker gets checked in,
and review/sr requests become "bugs", then these numbers (particularly the
"open" ones) will be even less representative of anything than they have ever
been. And we should not be exposing people to easily misinterpreted, meaningless
statistics.

The top section looks a mess (breadcrumbs overwritten, image too large, text
overlapping wrong) in IE 6 on Windows, and there are some funky alignment issues
with the columns in NS 4.7. :-(

CCing Dave. Dave - what's your view on this whole thing?

Gerv
Please.. the breadcrumbs are only for bmo.. don't let this hold up review of the
interface.

I like the statistics, and our engineers would surely like to know those counts.
If bmo doesn't want them, leave them out of their custom template - we have
customizable templates, you know? ;-)

If that's all people are disagreeing with, can we move on?
I think Dave should sign off on it first. He's The Man. If he's cool, I'll stop
complaining and start discussing implementation :-)

Gerv
> How about: 124559 bugs filed, of which ...
Good idea.

> The top section looks a mess ... in IE 6 on Windows ...
Note to self from the cafe: @#$%!ing Internet Explorer for Windows doesn't
@#$!ing understand {font-size: inherit;}, so the headings in the banner enlarge 
by the default factor for H1 and H2. So, the H1 and H2 need to revert to DIVs.
This looks nice and all on first inspection - y'all should bear in mind bug
#130835 which is probably orthogonal to this although related.

Although if you think we're going back to this page having no footer I suspect
you're in for a suprise.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
*cough* related to bug #109692.
> Internet Explorer for Windows doesn't @#$!ing understand {font-size: inherit;}, 

How about font-size: 1em; or font-size: 100%;? This should have the same effect.
Attached file Mockup version 5 (obsolete) — 
Changes in what is hopefully the final mockup:
*   fixed the mozilla.org header for MSIE for Windows (Gerv)
*   used hidden HRs to make the page suck less in Netscape 4.x (Gerv)
*   clarified the stats wording (Gerv)
*   clarified the column headings (Tim Powell, jorge o. castro, Ralph Mellor)
*   switched to Unicode bullet characters (Sascha Claus)

> How about font-size: 1em; or font-size: 100%;? This should have the same
> effect.

IIRC I tried that, but as with font-size: inherit;, MSIE was wrongly
multiplying by the default size of H1/H2 rather than by the size of the parent
element.
Attachment #84762 - Attachment is obsolete: true
Attachment #84770 - Attachment is obsolete: true
The column headings on the bug lists seem wonky.  The first column looks OK but
the for the other three the first line of the header is not lined up with the
second.
A few more comments:

In Konqueror 2.1.1 the default font size for the titles is a bit small.

It still looks like a pile in NS 4.x on Linux. Grey background, black-on-black
for highlighted tab, the new two-line titles don't line up, the buglists are
still horizontally unaligned (dunno what happened to your hidden HRs). CSS is
all very well, but NS 4.x is still a supported browser for Bugzilla, and the
current layout just isn't usable. :-(

Unicode dash characters don't work in titles on many browser/OS combos. On
Linux, Moz and Konq get it wrong; NS 4.x gets it right.

Gerv
*** Bug 134632 has been marked as a duplicate of this bug. ***
I like this, but I'm concerned about the back end...

The caching idea mentioned at the bottom of comment 0 is good, but how 
does that affect installations with bug groups on all their products, since a 
cached page could only show public bugs normally...
The cache needs to hold confidential bugs, meaning more than 10, and it would
show the ten that are accessible.  As to how many it shows, that needs to be
computed.

Presumably it's enough to work out the first ten for each possible groupset, but
that's probably not particularly optimal.  Better algorithms are non-obvious to
me at the moment.
I was thinking for each group restriction maintain counts of bugs both in and
out, and you know you're done when all the in and out counts for each group
passed the number needed.  But I can't prove this would work and I don't think
it would now.

One possibility is to consider the fact that the caching is only for performance
reasons and only cache the data for common groupsets.  However this would mean
uncommon groupsets would get up to date data while common groupsets wouldn't,
and this could be confusing.
It looks to me like comment 34, comment 35 and comment 36 are talking about
caching in case of personalized page, which is not the case here. First version
should be using these fixed columns and cache only those. 

This brings me to suggest showing "HELPWANTED" bugs, but this is based on
Keywords, not bug status. But those are bug that need most attention from
public. I also don't know which column to drop (four are maximum)... Maybe
better solution would be to create common searches...

I suggest adding "Common searches" right under Quick search. It would also serve
as separator between interactive-app part of the page and rest. These should
include most often used searches like: Filed today; Helpwanted bugs; etc (please
suggest more, what searches do you do regularily? - basicly those should be all
other candidates for front page columns). These could be also cached, like those
on front page. There should be around 6 of these, to avoid bloat and to fit in
aprox. one line. I'm not sure about the wording either. 
Somehow, my complaint about how Mozilla's menus work got marked as a dup of this
bug. It's NOT!

> It looks to me like comment 34, comment 35 and comment 36 are talking about
> caching in case of personalized page, which is not the case here.

They aren't - they are talking about bug groups, where certain bugs are visible
to only certain people. If these lists were to be cached, they would need to
contain only bugs that everyone can see. On b.m.o, that's most of them, but on
some installations, that's zero bugs.

> This brings me to suggest showing "HELPWANTED" bugs, but this is based on
> Keywords, not bug status

Only one Bugzilla installation has this keyword, so this couldn't be a default.
However, it might make sense to make the query which produces each column be
configurable in some way.

Gerv
Do I have a go-ahead on this index page design? I would like to start work on
this next week, so if you don't agree with it, speak up and avoid me wasting effort.

Obviously people will want all sorts of new features. I will assume the minimal
implementation of the exact page is what is accepted as a fix for this bug.
Status: NEW → ASSIGNED
Kiko, I thought we already did.  There needs to be some way of this page being
useful for more than non confidential bugs.

This might mean allowing disabling the feature, but that would leave the page
pretty barren.

Also, how are we going to get the "unreviewed" section working, given it's an
installation specific keyword?  I'm really hesistant to add yet another param.
Just make the template contain enough commented out bits + variables that the
admin just has to change a var at the top.
bbaetz: I'm not with you. What you said sounds very vague.

MattyT is right. We need a design - define exactly how this would work - before
we implement. Currently, there are several issues which have been raised which
need addressing before implementation should start.

Gerv
I was responding to the:

"Also, how are we going to get the "unreviewed" section working, given it's an
installation specific keyword?  I'm really hesistant to add yet another param."

bit.

The answer is to hard code teh 'review' keyword, but do so in a BLOCK with a
param. index.html.tmpl would contain a number of these blocks, (the columns in
the mockup), and admins can customise which ones are shown just by moving the
PROCESS directives arround.
bbaetz: so the blocks do a SendSQL pull?  Any thoughts of keeping admins from
pulling confidential data?
If they are admins, they can see all the bugs anyway.

I'd like to keep away from the "pull" model in Bugzilla's default templates. We
want to keep presentation separate from data gathering as much as possible.

Maybe the answer is for the default template not to have that column, but b.m.o
to do a customisation to get it.

Gerv

Well, they can either do an sql pull from the template when displaying, butI
thought that that part was going to be staticly generated via a script or something.

The template which is used to dump this to a file would have some functions
pushed to it, and it would call [% foo = GenerateKeyword("review") %], or whatever.

IE have the calls in perl, but have them called via the template once per hour
(or whatever)
My point is - if we're only going to be discussing the backend implementation,
and the UI is settled upon, then let me worry about it while I'm implementing
it. OK?
Earlier, I said:

> We need a design - define exactly how this would work - before
> we implement. Currently, there are several issues which have been raised which
> need addressing before implementation should start.

I believe that's still true. Once code is written, rightly or wrongly, there's
much more of a resistance to change it if the Right Way is subsequently proved
to be something else. I'd feel much better about the whole thing if there was a
design document. Kiko: you're the man who's writing presentations about the
development process; surely you understand the need for design before code? :-)

Gerv
Gerv, it would be a shame if this was being held up because you were waiting for
an answer which nobody knew the question to. :-) What exactly don't you
understand about the design? And what do you mean by a design document? I could
attach an amalgamated HTML version of comment 0 + attachment 85266 [details] + comment 42
+ comment 44 + comment 46, if that would suffice. Has there been a design
document for any previous change to Bugzilla, which I could use as a template?
If we can fix the remaining cross-browser issues, I'm not opposed in principle
to the implementation. My worry is that this mechanism for generating lists to
go on the front page will not be extensible enough, or be too mozilla-org or
large-site specific. Hence, I requested that kiko write down exactly how that
part would work technically (information which has not yet been placed in this
bug) in order that I might reassure myself that my fears were groundless.

I don't know if previous bits of Bugzilla have had public design documents, but
we have had implementation detail discussions on major changes. And, as day by
day I learn how to be a better software developer, I begin to appreciate the
value of a written design :-)

Gerv
Blocks: 65929
Attached image Mothla placeholder graphic (obsolete) — 
'cuz I'm bored...

If changing Mozilla.org's graphic won't get me into trouble, I can
provide the eps format & sketch on request
A few more thoughts:

- It sadly still remains the case that either Bugzilla will have to drop support
for NS 4.x or this page needs reworking. It looks unacceptably poor in NS 4.x
for Unix, at any rate.

- some of the current design is b.m.o-specific. (This is not a bug; it was
designed that way). This does mean, however, that we need to decide which bits
are going to be part of Bugzilla proper.

- The stats at the bottom of the page should be generated using the generic
charting mechanism (bug 16009).

- We need to work out how this work meshes with our nice new mascot over in bug
100095.

- The current design gets rid of the list of preset queries and the list of
things to administer from the footer. I think these features are pretty widely
used and, although we now have <link> equivalents for both of them, we need
something for browsers which don't support <link>.

- Currently, there's a really useful "Find bug" box in the footer. We have this
on the front page mockup, but it's not clear whether there will be anything
similar on other pages.

- The Request Tracker has added an extra link to the footer relating to managing
requests relating to you. This may need to be included in the tab list.

- If this is ever implemented, I believe it should be done in two stages. We
should do the UI stages (tabs, header, footer changes) first, and then do the
auto-generated buglists in a separate patch. This has the advantage that we can
get the UI improvements much earlier, as they are the simpler half of the patch.

I do want this bug to progress, our current UI is fairly widely held to suck,
and I think tab-style navigation UI is great, but we do need to resolve some of
these issues.

Gerv
Attached file Mockup version 6 — 
Netscape 4 should remain a supported browser for Bugzilla, for as long as (a)
the Mozilla Organization is developing Bugzilla and (b) a plurality of users of
Mozilla distros are suffering from bug 107694 (so Netscape 4 is likely to be
their backup browser when filing Mozilla bugs). With that in mind, this is a
tweaked version which contains just enough HTML 4.01 Transitional sugar to look
ok in Netscape 4.79 for Windows (and better in MSIE 5.0 for Windows). If it
still looks crappy in Netscape 4 for Unix, please attach a screenshot.

I disagree that the summaries at the bottom of the page should wait until bug
16009 is implemented -- that seems tail-wagging-doggish to me. (The
front-page-generating code could certainly be refactored to use the generic
charting once it is implemented.) I also disagree that the tabs should be
introduced separately from the buglists: when you change the design of a
commonly used item, pain is minimized (and probability of success is maximized)
if you change it all at once rather than in dribs and drabs. (I seem to recall
Gerv himself saying this somewhere, but I can't find it now.)

I think the rest of Gerv's points are covered by comment 7 point 1.
Attachment #85266 - Attachment is obsolete: true
Attachment #101878 - Attachment is obsolete: true
> that seems tail-wagging-doggish to me.

Fair enough.

> I also disagree that the tabs should be introduced separately from the buglists: 

You misunderstand me; I said they should be separate patches, in order to reduce
the complexity of the change and ease the burden on reviewers. The Bugzilla team
is moving towards trying to implement function in smaller chunks. The amount of
time which elapses between the checking in of these patches is not defined. It
could be as little as a week - it depends how much time the implementer has.

> I think the rest of Gerv's points are covered by comment 7 point 1.

I don't agree - your mockup removes functionality which is both useful and not
duplicated. In other words, it's a functional regression. If you think these
things shouldn't be present on the front page, then you will need to define, or
at least suggest, where they are present in the Bugzilla UI as a whole. i.e.:
- Will there be search or "find a bug" on every page? If so, where will it go?
- How will a Bugzilla user access their request queue?
- How will an administrator using IE access the list of things they can administer?
- Do people have to access the Advanced Query page in order to run a stored
query? I know you don't like these and think people should be using bookmarks,
but the fact remains that they are widely used.

I'll try your new mockup in Netscape 4 on Unix when I get home; it looks OK in
Netscape 4 on Windows except for the lack of a proper header. I think you should
be using <h1> or <h2> for the header, and working around IE/Win's bugs in
another way - it's the browser that's getting it wrong, after all.

I'd also like to hear your thoughts on which bits of your mockup are not
appropriate for the default Bugzilla in CVS (i.e. what bits are
bugzilla.mozilla.org-specific.)

Gerv
> You misunderstand me;

...or I was insufficiently clear. :-)

One other point: "Home" is still black-on-black in Netscape 4 - but this can be
fixed by getting a template to generate the stylesheet and moving the text
colour style into a simpler CSS rule than the one 4.x is ignoring. So it's not a
problem.

Gerv
Remaining problems in 4.x Unix (easier to describe than make a screenshot):

- Bullet characters for e.g. "Advanced Search" show up as ?.
- No heading (all the text on the page is body text-sized)
- Background is grey rather than white.
  Grey is the default for NS 4.x Unix. You could argue that people should 
  reconfigure their browsers, I suppose - but people don't. And it can be fixed
  by using bgcolor on the <body> tag.

So nothing incredibly serious - but I'd regard the lack of a heading as a
reasonably bad bug. It does make the page look very odd.

Gerv
> - Will there be search or "find a bug" on every page?
It could go in the top right corner, opposite the header (a la Google).

> - How will a Bugzilla user access their request queue?
No idea. How do they access it now? I'm logged in, and it's not in my footer.

> - How will an administrator using IE access the list of things they can
> administer?
Hmmmm. That would only need to be on the front page, not every page.

> Do people have to access the Advanced Query page [...] to run a stored query?
Yes.

> which bits of your mockup are not appropriate for the default Bugzilla in CVS
The Oldest Unreviewed column, and of course the customized header. That's all.

> - Bullet characters for e.g. "Advanced Search" show up as ?.
> - No heading (all the text on the page is body text-sized)
Suggestions on how to fix these without breaking anything else are welcome. :-) 
(Meanwhile, between mockups 5 and 6 I seem to have broken something in IE/Mac.)

> Background is grey rather than white. Grey is the default for NS 4.x Unix.
See also <http://www.yahoo.com/>. If it weren't for the CSS which defines 
different colors for bugs of different severities, I'd remove the background 
color from the CSS too, since it's mildly rude to override the user's default.
> > - How will a Bugzilla user access their request queue?
> No idea. How do they access it now? I'm logged in, and it's not in my footer.

It's a new (and much-requested) feature, not yet available on
bugzilla.mozilla.org, for tracking review requests etc.

> > - How will an administrator using IE access the list of things they can
> > administer?
> Hmmmm. That would only need to be on the front page, not every page.

Or a single link everywhere which takes you to a list.

> > Do people have to access the Advanced Query page [...] to run a stored 
> > query?
> Yes.

I'd say that's a functional regression. Part of the point of stored queries is
that they are quickly accessible. This is one of the reasons we gave the front
page a footer.

> > which bits of your mockup are not appropriate for the default Bugzilla in 
> > CVS
> The Oldest Unreviewed column, and of course the customized header. That's all.

The default Bugzilla needs a smarter header, though. Any ideas on adapting this one?

> > - Bullet characters for e.g. "Advanced Search" show up as ?.
> > - No heading (all the text on the page is body text-sized)
> Suggestions on how to fix these without breaking anything else are welcome. 
> :-)  (Meanwhile, between mockups 5 and 6 I seem to have broken something in 
> IE/Mac.)

You could fix the bullet characters by using graphics, hyphens, zeros or any
other more common character. Looks less nice, works better. 
You could fix the heading problem by actually using an <h2> or <h1>. :-) if IE
something-or-other gets it wrong, let's work around it using CSS hacks. Look up
Tantek Celik's box model hack - I think that makes it possible to have IE
5-specific CSS.

Gerv
I read about the problem of stored queries, and where could go "search by bug
number" stuff, and thought maybe something from this could help:
http://bugzilla.mozilla.org/attachment.cgi?id=99798&action=view
(well it is screenshot for site-navigation, but if you look behind menu, you can
see preset queries and search by bug number stuff)

i took idea from the attachments of this bug and tried to integrate it existing
version

if necesarry, i can save it also as .html
follow comments in next attachment
Attached file tm's mockup #1 — 
Since unfortunately nothing mutch is still happening here, i thought, i'll put
another working version of bugzilla.
Here are two things done, which are not necesarrily related:
1. Redesign of frontpage, using CSS
2. Custom additional template to show bugs today, my bugs, and mine to be
checked bugs on first page

I am willing to take over this bug, and at last take it to at least first stage
(simple 1stpage redesign). 
Comments, please?
I'm still quite keen on mpt's mockup.

The thing is, there are as many front pages as there are Bugzilla's; what we are
trying to find is something that makes a good default (and looks nice). That
argument has been made for the mpt mockup, but not yet for yours...

Gerv 
I prefer Toms' mockup (Comment 62).  It is a lot easier to understand and easier
to read than the mpt's version (Comment 54) and it closely matches how I work
with bugzilla.  I do like the tabs in mpt's version, though.
The page was inspired by mpt's Mock-up version 6 (attachment 101956 [details]) and Gerv's
comments.

I wanted a page that appealed to the bugzilla newcomers (I'm sure most
old-timers just jump directly to the query page.  The panels listing most duped
and popular REF's are an attempt to prevent even more duped bugs.  The panel
listing helpwanted bugs is to encourage participation.	The panel of blockers
is to keep people informed.

Let me know what you think.
Nice. :) Can you leave the underlines in, though? It's harder to understand the
page without them.
at small screen widths the bullets waste too much horizontal space, would you
mind css styling the bullets to be less wasteful, or perhaps dropping the
bullets entirely in favor of some other formatting?
The new mockup looks really nice (especially the colors!). I think product (at
least) should be added to buglists, to make it easier to orientate in bug.

regarding my version - gerv - i added only the layout stylesheet, i can also add
basic-theme stylesheet for colors, but i consider it of secondary value (i am
also not very good at coloring), since at first, i think, it should be figured
out how it all could look, and only then the nits. of course, that's only my
opinion. You can then make them look like tabbed browsing with ease (using
borders,colors and padding for links)

also, i think, since bugzilla is another do-it-right project, much attention
should be payed to correctness of CSS.
Reandom comments on Ian Pottinger's attachment 118748 [details]:

Overall, I like it. I'm not sold on the colour scheme and I'm afraid to say I
don't like any of the bug images but it's nice. Except...

* It claims to be XHTML 1.0 when it's HTML 4.01 Transitional. I don't think the
buttons are really needed anyway.

* There's one CSS error and several warnings.

* The text for the bug descriptions (in the columns) is far too small. If it was
just 20% larger it would be fine.

* There's no quick access to the user's saved queries. I think just underneath
the search box would be a nice place.

* Maybe the far-right column should be moved to the left. People read
left-to-right and that's the most important part, for a new user at least.

* It's RFE not REF. :-) And you don't really need to use an <acronym> tag if
you've just printed the expanded form.

* 'Bugzilla Today'? This isn't Outlook! I think 'Home' was fine.

* The page is declared to be ISO-8859-1 (and it is) but can it be guaranteed
that this will always be the case? If someone uses a funky character in one of
the bug summaries, will it be encoded into ISO-8859-1 before it appears in one
of the lists? (Gerv might know the answer to this.)
*IF* we declare a charset, it will be utf-8.
I need to learn more about UTF-8 before I replace the charset=ISO-8859-1"
declaration.  Nevertheless, I've submitted this versions which incorporates the
following suggested changes:

* does not block link underlines

* removes bullets

* includes animated bug logo

* replaced XHTML 1.0 button with HTML 4.01 

* corrects CSS warnings

* increases the size of the text for the bug descriptions

* adds quick access to the user's saved queries

* swaps positions of the left and right columns.

* corrects "REF" to "RFE" and removes <acronym> tags.

* replaces 'Bugzilla Today' with 'Bugzilla Central' (I loath 'Home').

* improved response to page resizing and text scaling

This was more of a personal exercise and may very well be inappropriate for the

needs of buzilla.org. However, I've shared it here and I'm more than willing to

make any required changes if buzilla.org wishes to use it.
Attachment #118748 - Attachment is obsolete: true
>I need to learn more about UTF-8 before I replace the charset=ISO-8859-1"

if you only use US-ASCII characters, UTF-8 is compatible with ISO-8859-1.
Re: attachment 118851 [details]

Looks good.  However, I think that "striked through" should be changed to
"struck through".  Also there is still an REF (instead of RFE) on this page.
A couple of trivial things:

 - The "Blockers of Next Release" column has a typo; it currently says "verion"
in the explanation at the bottom.
 - I'm using a high-res display, but I'm thinking that those with lower-res
displays will get extremely narrow columns under the "Bugs of Interest" section.
Seeing one word per line is a little annoying to read. Maybe the columns could
be stacked horizontally, rather than vertically?
 - The Login tab could be given a light background other than white, so that
people who would usually login first can jump to it a little quicker.

That said, I like that subtle animation in the logo and site icon, and I like
the use of color. Thanks for spending your time on this bug.
The typos and suggestions that both Stephen and Minh mention will be included in
the any future update.

Your suggestions are appreciate.  Please note that CSS min-width has been
applied to the "Bugs of Interest" panels to prevent them from becoming too thin
(works in mozilla but ignored in IE) and they are free floating so that they
will stack themselves as the width of the window decreases.  I use a high-res
screen so I almost never have that problem but I tried to plan for it.  Should I
increase the min-width?
At a window size of 640 x 480, one of the columns does wrap to below the others,
but the columns are so narrow that they display one or two words per line, and
they are also very long. In addition, two of the tabs at top wrap, overlapping
part of the "Search" and "Report a Bug" tabs. This might be a nice effect, but
you'd need to somehow make the tabs go a bit lower when they wrap. Adjusting the
"line-height" might solve this.

One more thing, you might want to have the "mozilla.org" at the top link to
mozilla.org. (Just a reminder.)
Please see also bug #203709: another redesign of index.cgi, but targeted to a
completely different user group. It addresses the needs of developers and
testers. It has also some working code.

I am not asking for any change to *this* redesign but I would appreciate it if
you check out and comment on my design too.
I’m Canadian, so it is in my nature to find compromise.  Please see bug #203709
for my comments.

I’ve been extremely busy (especially these past 3 weeks) with the launch of my
employer’s redesigned website, a major effort that robbed me of 9 months of my
life.  It finally done and with its birth I can start *my* life anew.  That
said, I’ll try and post an updated mockup shortly.

Ian: please don't do that - at least, until you say what's wrong with attachment
101956, a design by a usability expert which has been through several levels of
review and quite a lot of cross-browser testing.

Multiple alternative designs makes this bug less likely to be fixed, not more,
because before anyone can fix it there has to be a big argument about which
design to implement.

Gerv
Redesigning bugzilla is a terrific idea. For a short story about my first-time
experience trying to vote for a bug/enhancement, see here:

http://forums.mozillazine.org/viewtopic.php?t=19738
Depends on: 224595
Assignee: kiko → nobody
Status: ASSIGNED → NEW
Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
Target Milestone: Bugzilla 2.22 → ---
Depends on: 203709
gandalf is working on its rewrite, using AJAX.
Assignee: nobody → gandalf
Blocks: ajax
QA Contact: mattyt-bugzilla → default-qa
Target Milestone: --- → Bugzilla 2.24
This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2
Priority: P3 → P1
Summary: Redesign Bugzilla front page (index.cgi) → Make Bugzilla's index.cgi (home page) useful for logged-in users
No longer blocks: 51100
Depends on: 109692
Depends on: 390955
I'm reassigning this back to "nobody" since I haven't seen any work on it in a while.
Assignee: gandalf → ui
Keywords: ue
Assignee: ui → guy.pyrzak
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0
Blocks: 417438
Status: NEW → ASSIGNED
Whiteboard: [roadmap: 4.0]
Various points in pyrzak's student's research indicate that this is a particularly important issue.
Blocks: bz-hci2008
reassigning this b/c he's made a lot of progress with the sql query stuff and worst case I can help with some UI clean up if necessary.
Assignee: guy.pyrzak → jonathan
(In reply to comment #77)
> Please see also bug #203709: another redesign of index.cgi, but targeted to a
> completely different user group. It addresses the needs of developers and
> testers. It has also some working code.
> 
> I am not asking for any change to *this* redesign but I would appreciate it if
> you check out and comment on my design too.

Although resolved as a duplicate I think reconsideration of attached layout should be considered. IMHO the layout shown in this mockup has way to many columns. 
In the last mockup I count no less than five. Even though in the mean time we have more and more users using a widescreen lots of valuable screenspace is wasted by seperating the columns as well as lots of lines being used for the description. I can see some issues rising up with wrapping of larger words in summaries.

Most webinterfaces limit their columns to maximum three, I think bugzilla should try and adhere to this standard. The suggested mockup in bug 203709 is adhering more to this standard than the mockup here (although it might have some points of improvement)

Apart from that I am wondering about the progress on this bug as I do not see much progress other than closing of a lot of duplicates in favor of this one which seems (at least) stalled to me.
(In reply to comment #95)
> reassigning this b/c he's made a lot of progress with the sql query stuff and
> worst case I can help with some UI clean up if necessary.

Thanks, but I am not sure n what to do next. I have some serious objections to the mockups and am in favour of the one in bug 203709. I am not sure if I am willing to progress on this one. I would rather work on integrating the version of bug 203709 into bugzilla.
the mock is not necessarily a "this is how this must be done" in fact i think what you're doing is a great step in the right direction in making the homepage useful for logged in users. So my point was, keep going in the direction you are going in.
Moreover, all mockups here are 7+ years old, and many comments are from developers who are no longer contributing for at least 5 years. Let's say you are free to start from scratch (or from what you did in the other bug).
Specifically continue to integrate frontpage.cgi into index.cgi. We can work on what shows up for not logged in users but for logged in users Frontpage.html.tmpl might completely replace index.html.tmpl. 

Hopefully that helps explain that you shouldn't change the direction you were going in for the previous bug but instead continue as if you are on the same bug. I think bug 203709 was always a dup of this bug.
(In reply to comment #98)
> the mock is not necessarily a "this is how this must be done" in fact i think
> what you're doing is a great step in the right direction in making the homepage
> useful for logged in users. 

The original work is not mine, but I liked it and reworked it to work on more recent bugzilla versions.

(In reply to comment #98)
> So my point was, keep going in the direction you are going in.

(In reply to comment #99)
> Moreover, all mockups here are 7+ years old, and many comments are from
> developers who are no longer contributing for at least 5 years. Let's say you
> are free to start from scratch (or from what you did in the other bug).

Based on above, wouldn't it be fair to reopen bug 203709 and remove the duplicate mark pointing to this bug? Or assign the duplicate the other way around (making this a duplicate of bug 203709)?
(In reply to comment #100)
> Specifically continue to integrate frontpage.cgi into index.cgi. We can work on
> what shows up for not logged in users but for logged in users
> Frontpage.html.tmpl might completely replace index.html.tmpl. 
> 
> Hopefully that helps explain that you shouldn't change the direction you were
> going in for the previous bug but instead continue as if you are on the same
> bug. I think bug 203709 was always a dup of this bug.

I already understood that :)
(In reply to comment #101)
> Based on above, wouldn't it be fair to reopen bug 203709 and remove the
> duplicate mark pointing to this bug? Or assign the duplicate the other way
> around (making this a duplicate of bug 203709)?

No, because 1) this bug is older and takes precedence, 2) it a much larger audience (52 CC'ed users + 26 votes), and 3) it has numerous dependencies. So this bug is definitely where work must happen.
The simple, basic start to this is to provide a patch that does nothing but show certain saved searches in boxes on index.cgi for logged-in users. This is very simple to accomplish using iframes and the "simple" format of buglist.cgi.

Once we have that done, we can add other useful information to the page.

I agree that it should be no more than 3 columns.
While I am very much against stopping any work being done on something until it's planned out in extreme detail, the high visibility of the front page means that if we add stuff and then remove it later, people might get upset. Is it not worth at least having an agreed pencil sketch of where we want to get to (a bit more detailed than "other useful information") before we start?

Or have you blessed one of the mock-ups attached to this bug?

Gerv
(In reply to comment #105)
> While I am very much against stopping any work being done on something until
> it's planned out in extreme detail, the high visibility of the front page means
> that if we add stuff and then remove it later, people might get upset. Is it
> not worth at least having an agreed pencil sketch of where we want to get to (a
> bit more detailed than "other useful information") before we start?

Fine by me, but it seems this discussion has not been started the last few years and this bug is almost 6 years old by now. Do you see it get started or even concluded in the near future?

Personally I think it should list bugs related to the current user (when logged in) or the current page (when not logged in), see the list of implemented features below.

> Or have you blessed one of the mock-ups attached to this bug?

I have not and dislike them all. I therefore would like to obsoleted them all, but it seems I can not (at least not ATM).

I have done some rework of my (re)work attached to bug 203709. The original idea is not mine, but I liked it and therefore reworked the code to work with 3.4.4 (which I was using). 
After some discussion in mentioned bug this bug was assigned to me and my other closed as a duplicate and I was assigned this bug.

I will hereby attach my patch (against Bugzilla's current tip) which will show a different layout of the home page (for logged in users). IMHO it makes the home page a lot more useful to logged in users as it will display:

* a list of active products with the open bug tally per product
* usefull links for the user like:
  - link to advanced search (query.cgi)
  - link to new bug (enter_bug.cgi)
  - link to reports page (reports.cgi)
  - logout
  - search box
  - add to sidebar option
* A list of bugs related to the logged in user, currently 
  differentiated in:
  - Assigned to you (the issue has been assigned to you and it is 
    not resolved or closed yet)
  - Retest (you reported this issue, it is now resolved and you should 
    verify it)
  - New (you reported it but nobody has accepted it yet)
  - In progress (you reported it, the developer accepted the issue 
    and is hopefully working on it)

Currently the statuses and resolutions are still hard coded which is a no-no according to bug 203709 comment 56. I will fix this in the near future.
(In reply to comment #106)
> Currently the statuses and resolutions are still hard coded which is a no-no
> according to bug 203709 comment 56. I will fix this in the near future.

Not only is this a no-no, but this is something you have to think about now as you probably cannot define what is "accepted" and what is not.

Two more things:
- Could we have screenshots of the proposed new UI? That's much more useful for us while we decide what we want to see in the page and how to display the information. When we agree on the UI, we can focus on the backend code.
- You totally bypass security checks. You must call Bugzilla::Search to get buglists. This has the advantage of also removing all your SQL calls from index.cgi.
Actually, instead of using Bugzilla::Search, you can also call the simple format of buglist.cgi in an iframe. (buglist.cgi?format=simple)
(In reply to comment #107)
> Not only is this a no-no, but this is something you have to think about now as
> you probably cannot define what is "accepted" and what is not.

I am not sure what you mean exactly by that. What do you mean with "accepted". What might be accepted or not? And by whom? 
Are you referring to the information being displayed on the home page as outlined in comment 106?

> - You totally bypass security checks. You must call Bugzilla::Search to get
> buglists. This has the advantage of also removing all your SQL calls from
> index.cgi.

If that is common practice I might rewrite stuff to get it working, however I do not see much risk here as the queries are defined in the code and the only parameters are enforced by the prototypes of for instance the user class to have the proper value and proper type (e. g. user->id), so issues like SQL injection are highly unlikely if not absent in these cases.

(In reply to comment #108)
> Actually, instead of using Bugzilla::Search, you can also call the simple
> format of buglist.cgi in an iframe. (buglist.cgi?format=simple)

Although that might be an easy option I dislike the use of iframes. For me even a bigger issue is me not being satisfied with the looks of the buglist displayed by it as it will shorten a lot of valuable information which I would like to see displayed full and not abbreviated. I am referencing to headers like "Comp" for the "Component" columns and the like but also the field values, for instance the 7 character codes for components, 4 character shorthand for resolutions.
(In reply to comment #106)
> Fine by me, but it seems this discussion has not been started the last few
> years and this bug is almost 6 years old by now. Do you see it get started or
> even concluded in the near future?

Perhaps the lack of interest in having a discussion is a reflection of lack of interest in the feature as a whole? After all, if people were clamouring for a "more useful" index.cgi, wouldn't they be talking about what "more useful" means?

Also, "no-one can be bothered to spec it, so we'll just implement it without a spec" doesn't sound like a great way to develop software to me.

AIUI, actually, there has been some discussion, and there are mockups attached to this bug. Also, the last time we changed the front page, the reaction was negative enough that several UI designers dropped their paid work to design better front pages for us. Has any of that feedback been considered for the current design? Have we reached out to those people with the ideas we have?

> Personally I think it should list bugs related to the current user (when 
> logged
> in) or the current page (when not logged in), see the list of implemented
> features below.

What do you mean by "related to"?

> > Or have you blessed one of the mock-ups attached to this bug?
> 
> I have not and dislike them all.

Sorry for being ambiguous; that was a question for Max.

Let me play devil's advocate, if you will forgive me:

> * a list of active products with the open bug tally per product

How is this information actually useful, apart from to impart a sense of dread and hopelessness?

> * usefull links for the user like:
>   - link to advanced search (query.cgi)
>   - link to new bug (enter_bug.cgi)
>   - link to reports page (reports.cgi)
>   - logout
>   - search box
>   - add to sidebar option

So these links will now be present on the page 3 times (header, footer, body) instead of 2?

> * A list of bugs related to the logged in user, currently 
>   differentiated in:
>   - Assigned to you (the issue has been assigned to you and it is 
>     not resolved or closed yet)
>   - Retest (you reported this issue, it is now resolved and you should 
>     verify it)
>   - New (you reported it but nobody has accepted it yet)
>   - In progress (you reported it, the developer accepted the issue 
>     and is hopefully working on it)

If there are more bugs than fit on the page, how do you choose which to display?

Gerv
(In reply to comment #110)
> Perhaps the lack of interest in having a discussion is a reflection of lack of
> interest in the feature as a whole?

  That is absolutely not the case. This is a very-frequently-requested feature, and it came up in the HCI research as well.


  In general, instead of questioning the value of the implementation that has been posted, I'd rather see some concrete suggestions or some actual code work. Or alternately, specific review comments on the posted patch that directly point out actual problems or make suggestions as to what should be done instead.
(In reply to comment #109)
> If that is common practice I might rewrite stuff to get it working, however I
> do not see much risk here as the queries are defined in the code and the only
> parameters are enforced by the prototypes of for instance the user class to
> have the proper value and proper type (e. g. user->id), so issues like SQL
> injection are highly unlikely if not absent in these cases.

  Hey Jonathan. Product names can be confidential. Bug information can be confidential. So you have to use the various methods that Bugzilla provides for getting data, instead of direct SQL, to ensure the security of the system.

  $user->get_selectable_products() returns products that the user can search on.

  You can either use $user->visible_bugs() to limit returned bug ids to the ones that users can see, or use Bugzilla::Search to generate a buglist (which is standard practice for generating buglists).
(In reply to comment #111)
> In general, instead of questioning the value of the implementation that has
> been posted, I'd rather see some concrete suggestions or some actual code work.

I welcome them as I am not yet familiar with the Bugzilla coding practices, classes and functions. Thanks for supporting me in this.

> Or alternately, specific review comments on the posted patch that directly
> point out actual problems or make suggestions as to what should be done
> instead.

Yes, please.

(In reply to comment #112)
>   Hey Jonathan. Product names can be confidential. Bug information can be
> confidential. So you have to use the various methods that Bugzilla provides for
> getting data, instead of direct SQL, to ensure the security of the system.

I am aware of the security issues and will address them as I know it will never be accepted without it. I guess he mockup/patch I adapted/adopted was far from complete and not up to par for Bugzilla coding standards.

>   $user->get_selectable_products() returns products that the user can search
> on.
> 
>   You can either use $user->visible_bugs() to limit returned bug ids to the
> ones that users can see, or use Bugzilla::Search to generate a buglist (which
> is standard practice for generating buglists).

Thanks for the pointers. I have been reading and experimenting with Bugzilla::Search a little, but I am not fully comprehending the internals ATM. My little testing efforts so far (on my test data set) result in a list which is way to big as it seems to drag in every CC the user is in as well, which I do not desire).
(In reply to comment #110)
> Also, "no-one can be bothered to spec it, so we'll just implement it without a
> spec" doesn't sound like a great way to develop software to me.

I am happy to spec it first, but _my_ basic requirements are in my current implementations, unless convinced otherwise I will keep steering in that direction welcoming other suggestions and additions.

> What do you mean by "related to"?

Assigned to the current user, created by the current user, etc. as outlined in the last list of comment #106:

> * A list of bugs related to the logged in user, currently 
>   differentiated in:
>   - Assigned to you (the issue has been assigned to you and it is 
>     not resolved or closed yet)
>   - Retest (you reported this issue, it is now resolved and you should 
>     verify it)
>   - New (you reported it but nobody has accepted it yet)
>   - In progress (you reported it, the developer accepted the issue 
>     and is hopefully working on it)

> Let me play devil's advocate, if you will forgive me:

I will. :)

> > * a list of active products with the open bug tally per product
> 
> How is this information actually useful, apart from to impart a sense of dread
> and hopelessness?

I think you are approaching this from the negative site. I think it is informative to see a list of bugs per product, but if not desired it can be dropped from it. I left it in as I liked it.

> > * usefull links for the user like:
> >   - link to advanced search (query.cgi)
> >   - link to new bug (enter_bug.cgi)
> >   - link to reports page (reports.cgi)
> >   - logout
> >   - search box
> >   - add to sidebar option
> 
> So these links will now be present on the page 3 times (header, footer, body)
> instead of 2?

Again, these were in the original patch I adopted and although it might be a third time they are on the page I see not much harm in that, but they can be dropped as well if that is the feel of the majority.
 
> If there are more bugs than fit on the page, how do you choose which to
> display?

The nice part of a web page is that it's length is not limited by the height of the screen so the user can scroll up/down, but I agree with you that to long lists defy the use fullness. 
Suggestions are welcome, but I have been thinking that you can limit the list to a maximum number of bugs (say 20 or so) and provide a link (e. g. at the bottom of the list) to view the full list, a pager might also be possible although I have not seen it used in Bugzilla's screens anywhere, nor limiting lists if the bug count stays under a certain amount of bugs (1000 IIRC).
(In reply to comment #113)
> Thanks for the pointers. I have been reading and experimenting with
> Bugzilla::Search a little, but I am not fully comprehending the internals ATM.
> My little testing efforts so far (on my test data set) result in a list which
> is way to big as it seems to drag in every CC the user is in as well, which I
> do not desire).

  Yeah, Bugzilla::Search is tricky. You might want to come ask me in IRC about it, I'm there now and will be for several hours. ( http://wiki.mozilla.org/Bugzilla:Communicate )
(In reply to comment #107)
> - Could we have screenshots of the proposed new UI? That's much more useful for
> us while we decide what we want to see in the page and how to display the
> information. When we agree on the UI, we can focus on the backend code.

Here is an obfuscated (as I can not share the actual content) screen shot taken from my test setup to give you an impression. Keep in mind though that this is a draft.
(In reply to comment #111)
>   That is absolutely not the case. This is a very-frequently-requested feature,
> and it came up in the HCI research as well.

So did that research suggest _what_ people would find useful on the front page?

I'm fairly sure the vague statement from the title of this bug, "make the front page useful" was not a conclusion in the HCI report, although I stand open to being corrected and highly surprised.

>   In general, instead of questioning the value of the implementation that has
> been posted, I'd rather see some concrete suggestions or some actual code work.

My concrete suggestion is that we should talk to the people who had feedback the last time the front page of b.m.o. changed, and do some use case analysis on the proposals.

That is what comment 110 was beginning to do. I see from the recently-attached screenshot that the front page has a list of open bugs in each product. My question is: what possible use is that information? And is it really useful enough that people want to see it every day?

What sort of users are we expecting to visit the front page? I would expect it to be visited mostly by new users, because experienced users will go directly to the place they want to go to - by clicking a link in bugmail, or by typing "query" into their AwesomeBar, or whatever. If this is the case, then perhaps the front page would be better like this proposal:
http://jboriss.wordpress.com/2009/04/22/my-bugzilla-redesign-2%C2%A2/

If we want to have a "experienced developer dashboard" of the sort Jonathan's patch is proposing, then perhaps it could be at a URL other than index.cgi (although it might be linked from there).

Gerv
Personally, I like to know what happened since the last time I logged into Bugzilla. It would be great if recent changes could be displayed in the home page. But I have a saved search for this (changes to bugs in the Bugzilla product within 24 hours) and so I basically want the ability to choose which saved searches to run when logging in, to not have to run them manually. Ideally, only added/removed bugs from the buglists should be displayed, the existing ones being hidden by default. So we could have something like:

Bugs filed today: +4 / -6 (total: 15)

*bugs added to the list*
*bugs removed from the list*


Bugzilla blockers: +1 / -6 (total: 14)

*bugs added to the list*
*bugs removed from the list*


etc... for all saved searches I selected to be run automatically when I visit index.cgi.
(In reply to comment #117)
Gerv, you bring up a good point and it isn't clear to me what the right answer is. We initially agreed with your suggestion that new users will go to the homepage and experienced developers will not. Aesthetics aside that was the driving force behind the current homepage UI, and also what drove jborris's UI.

However, it seemed to me that many users felt that there should be a more "useful" page for logged in users. Looking at the screen shots and mocks that's what this bug requests. Now it is possible that you feel this bug is a "won't fix" and should instead be a separate page. But this bug does describe in all the mocks the "experienced developer dashboard".

As a side note there is a skin that supports the UI that jborris made but I need to fix it to support announcements better.
The assumption there is that "logged in user" == "experienced developer".  But I don't think that's true in most cases.  Perhaps a user preference is in order?  I tend to like the idea of embedding the results of saved searches in the homepage.  By default, it would embed the results of the "My Bugs" query (or some other canned query if that's not quite what's desired), but the set of queries is configurable.  (Wording below is TBD, of course.)

On the home page, display:
 [X] useful info for end-users
 [ ] useful info for developers
 --- saved searches
    [X] My Bugs             ( ) full list (o) recently changed
    [ ] My saved search 1   ( ) full list ( ) recently changed
    [X] My saved search 2   (o) full list ( ) recently changed
Oh, that preference panel is possible.

I think probably the simplest and most flexible solution here is at first to simply allow the display of Saved Searches, including My Bugs (which should appear by default) in an iframe on the logged-in index.cgi. I think that if we do that, we can get some feedback from users on what is most useful and interesting to them, and then we can adjust the defaults or add more features based on that feedback.
As discussed with mkanat on IRC and referenced in comments here as well I reworked the index page (for logged in users) to show saved searches.

I modified the preferences tab to have a show on index column, similar to the show in footer column to select which saved searches to display on the index page.

The looks are not very pretty yet as I still need to find out how to format the iframes to span the page width and have a hight preventing the scrollbar if possible, so it is more or less a proof of concept. I would appreciate a blessing to proof I am working in the right direction as well as comments and suggestions on how to improve.
Attachment #424100 - Attachment is obsolete: true
Attachment #424426 - Attachment is obsolete: true
Attachment #426847 - Flags: review?(mkanat)
Comment on attachment 426847 [details] [diff] [review]
Rework index page for logged in users to show saved searches

  I can't test this because saving the "Home Page" option on userprefs.cgi isn't working. (It doesn't save.)

> use constant UPDATE_COLUMNS => qw(name query query_type);
>+sub link_in_index {

  I think you also need to add this info to preload(), or create an accessor in Bugzilla::User that only returns home-page queries.

>Index: template/en/default/index.html.tmpl
>+        [% IF user.login %] 

  I want everything in this block to be in a BLOCK directive at the bottom of this template. The logged-out UI should also be in a BLOCK.

>+          <div style="font-size: 8pt; font-family: Verdana,Arial,Helvetica,sans-serif">

  You can put stuff into index.css instead of in a direct style tag.

>+            <table>

  You need cellpadding="0" cellspacing="0", and then this table probably needs an id or class for styling.

>+                      <iframe src="buglist.cgi?format=simple&amp;cmdtype=runnamed&amp;namedcmd=[% q.name FILTER url_quote %]">[% q.name FILTER html %] width="100%" ></iframe>

  I think you may want to put a limit on how many bugs are displayed here. When I was originally working on this, I made it a scroll-less, frame-less iframe with only the top five bugs displayed, although you could limit it to 100 or something and allow a scrollbar, if you wanted.

>Index: template/en/default/account/prefs/saved-searches.html.tmpl
>+        Show on
>+        Home

  I'm not sure that's descriptive enough. Also, I don't think you need that on separate lines.
Attachment #426847 - Flags: review?(mkanat) → review-
(In reply to comment #123)
> > use constant UPDATE_COLUMNS => qw(name query query_type);
> >+sub link_in_index {
> 
>   I think you also need to add this info to preload(), or create an accessor in
> Bugzilla::User that only returns home-page queries.

I will have a look into that as I am not sure at the moment what you mean by that.

> >Index: template/en/default/index.html.tmpl
> >+        [% IF user.login %] 
> 
>   I want everything in this block to be in a BLOCK directive at the bottom of
> this template. The logged-out UI should also be in a BLOCK.

Fine. Will do so.

> >+          <div style="font-size: 8pt; font-family: Verdana,Arial,Helvetica,sans-serif">
> 
>   You can put stuff into index.css instead of in a direct style tag.

Oops, forgot to remove that, this is a left over from copy-pasting code from the original source I guess. I will adhere to the normal way of using stylesheets over inline formatting.

> >+            <table>
> 
>   You need cellpadding="0" cellspacing="0", and then this table probably needs
> an id or class for styling.
> 
> >+                      <iframe src="buglist.cgi?format=simple&amp;cmdtype=runnamed&amp;namedcmd=[% q.name FILTER url_quote %]">[% q.name FILTER html %] width="100%" ></iframe>
> 
>   I think you may want to put a limit on how many bugs are displayed here. When
> I was originally working on this, I made it a scroll-less, frame-less iframe
> with only the top five bugs displayed, although you could limit it to 100 or
> something and allow a scrollbar, if you wanted.

Are these patches perhaps (still) available somewhere?

> >Index: template/en/default/account/prefs/saved-searches.html.tmpl
> >+        Show on
> >+        Home
> 
>   I'm not sure that's descriptive enough. Also, I don't think you need that on
> separate lines.

I welcome suggestions, but I took this in analogy with the "Use in footer" column, the line break is there as I tried to adhere to the original copy where I took the code from as IIRC "Use in footer" was in the source with a line break before footer as well.

I will rework my pathc and submit it here. Once again thanks for reviewing.
(In reply to comment #123)
> (From update of attachment 426847 [details] [diff] [review])
>   I can't test this because saving the "Home Page" option on userprefs.cgi
> isn't working. (It doesn't save.)

Strange, it works for me. Did you run ./checksetup.pl to create the required table?
(In reply to comment #125)
> Strange, it works for me. Did you run ./checksetup.pl to create the required
> table?

  I did, although your patch posted here entirely lacks any changes made to userprefs.cgi.

(In reply to comment #124)
> Are these patches perhaps (still) available somewhere?

  Mmm, unfortunately not. I think that I just deleted my work without posting it anywhere.

> I welcome suggestions, but I took this in analogy with the "Use in footer"
> column, the line break is there as I tried to adhere to the original copy where
> I took the code from as IIRC "Use in footer" was in the source with a line
> break before footer as well.

   Hmm, yeah, I don't have any suggestions at the moment. No need to adhere to the original formatting in this case--better to do what looks better and makes more sense.

  Also, did you plan to add the checkbox to shared searches as well?
Reworked my patch a little:
- now includes changes to userprefs.cgi which makes adding searches to the homepage possible
- added checkboxes to indicate where to show, but they are still defunct (as I need to investigate further how they are handled)
- moved code in templates in to [% BLOCK %] fragements as requested

TODO (I can think of quicly, most likely there will be more :) ):
- I have not found a better indication to replace the current "Show in home", suggestions are welcome :)
- Style the iframe as it now does not span the page, still has an ugly border and scrollbars
- Implement limit on total bugs listed per search ATM.

Please review as I welcome suggestions in order to get me up to speed as well as my coding style close to what is required to get this included into the codebase in the future.
Attachment #426847 - Attachment is obsolete: true
Attachment #428525 - Flags: review?(mkanat)
Comment on attachment 428525 [details] [diff] [review]
Rework index page for logged in users to show saved searches (v2)

Please disregard... it seems I have poisoned my tree when migrating from cvs to bzr. I will submit a clean(er) patch tomorrow (CET).
Attachment #428525 - Attachment is obsolete: true
Attachment #428525 - Flags: review?(mkanat)
what happened to the patch?
(In reply to comment #128)
> (From update of attachment 428525 [details] [diff] [review])
> Please disregard... it seems I have poisoned my tree when migrating from cvs to
> bzr. I will submit a clean(er) patch tomorrow (CET).

Jonathan: Do you have a new patch?
The promised patch, sanitized as compared to comment 128. Sorry to keep you waiting I got seriously side tracked and have a very busy schedule ATM.

I would like to know if this is an improvement over my v1, keeping in mind the comments in comment 127 still apply to this patch.
Attachment #440266 - Flags: review?(mkanat)
Attachment #440266 - Flags: review?(mkanat) → review?(guy.pyrzak)
Comment on attachment 440266 [details] [diff] [review]
Rework index page for logged in users to show saved searches (v3)


>+              [% FOREACH q = user.queries %]
>+                [% IF q.link_in_home %]
>+                      <h2>[% q.name %]</h2>
>+                      <iframe src="buglist.cgi?format=simple&amp;cmdtype=runnamed&amp;namedcmd=[% q.name FILTER url_quote %]">[% q.name FILTER html %]"></iframe>
>+                [% END %]
>+              [% END %]
>+[% END %]


Url_quote should change to uri

------

I looked at the UI and saw a few problems. 

1. There is no default homepage search query and no default way to show users what they should do to add one or make the homepage look the same as the normal home page. I think either loading in the preferences into an Iframe on the logged in homepage with instructions or just the normal homepage should show up OR a decent default like "My Bugs".

2. My Bugs isn't an allowed homepage search that seems like an oversite since that might the most common default homepage search.

3. Once you add a search to the homepage, at least on chrome, the iframe which loads the search results shows the information in a tiny iframe that isn't elastic and doesn't get in the sam area code as trying to stretch to fit the whole screen either vertically or horizontally.

Sorry for the late review
Attachment #440266 - Flags: review?(guy.pyrzak) → review-
Jonathan, do you plan on continuing to work on this bug?
Ian's second attempt is close to what I meant in bug 397517 comment 4. It looks oh-so-good. :)
Whiteboard: [roadmap: 4.0] → [roadmap: 4.2]
I'm guessing Jon isn't planning on coming back to this patch so i might continue it over the holiday break. since I think many people are hoping to see this capability sooner than later.
(In reply to comment #135)
> I'm guessing Jon 

It's Jonathan, thanks.

(In reply to comment #135)
> isn't planning on coming back to this patch so i might
> continue it over the holiday break. since I think many people are hoping to see
> this capability sooner than later.

I am very busy at the moment with other stuff, so please feel free to continue working on it. I would very much like to see bugzilla improve in this field.
Attached patch v4 — — Splinter Review 
taking this bug since we're going to get it in for 4.2. However 95% of this is still Jonathan's code.
Assignee: jonathan → guy.pyrzak
Attachment #440266 - Attachment is obsolete: true
Attachment #510220 - Flags: review?(mkanat)
Attachment #510220 - Flags: review?(LpSolit)
for those wondering the UI looks like this http://grab.by/8Ov2 based almost totally on toolness's UI.

For those interested this does introduce a hook as well as a fairly simple way to add other UI elements such as charts etc when they become available as saved items. 

One thing this homepage is totally lacking is a way of sorting/ordering the results on the page. We should discuss if this is something we want to bother with in the first iteration or not.
(In reply to comment #138)
> for those wondering the UI looks like this http://grab.by/8Ov2 based almost
> totally on toolness's UI.

Thanks Guy for continuing on this. This is an improvement to the use of iframes as I implemented as suggested by Max IMHO, but I am wondering how this will extend if a user might have more queries that would fit in a screen horizontally.
Would it wrap at the page and and start a new row below or is your patch just extending to the right placing things off to the right of the screen eventually?

> For those interested this does introduce a hook as well as a fairly simple way
> to add other UI elements such as charts etc when they become available as saved
> items. 

That is a nice extra feature. I would welcome that very much as it makes things easier to oversee in a quick glance to decide where to start off from the index page which should be the purpose IMHO.

> One thing this homepage is totally lacking is a way of sorting/ordering the
> results on the page. We should discuss if this is something we want to bother
> with in the first iteration or not.

I think sorting would be nice, but not a show stopper, even without sorting this would mean an improvement to the main page.
It still unfortunately uses iframes for now, mostly because we're waiting on webservices to support search, it just hides the widgets from users. The GUI follows toolness's UI though. 

In terms of wrapping, it doesn't, and purposefully so, it keeps going off to the right, we could have it wrap if we think that's preferable, easy enough to do.
(In reply to comment #140)
> It still unfortunately uses iframes for now, mostly because we're waiting on
> webservices to support search

Bug.search exists, see http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService/Bug.html#search
it doesn't support saved searches.
@mkanat. LpSolit and I were discussing the way the tables are implemented in the current patch could be improved. The improvement is instead of adding another column to handle homepages, instead add 1 column that is "Type" have 0 mean it should appear in the footer and 1 mean it should appear in the homepage. This would reduce the number of tables we need and not cause any problems with the current implentations of "in_footer" stuff and reduce the need for another table.
(In reply to comment #143)
> instead add 1 column that is "Type" have 0
> mean it should appear in the footer and 1 mean it should appear in the
> homepage.

  Ah, that's a nice idea in terms of space efficiency in the database, but we aren't worried about space efficiency for these tables. I think what would really happen there is that the SQL would become complicated and slightly confusing.

  What I'd suggest is actually implementing it and see how the complexity is. I haven't looked at the current patch, so I can't comment on that yet.
(In reply to comment #144)
> really happen there is that the SQL would become complicated and slightly
> confusing.

It wouldn't be complex or confusing at all. You would just add "AND type = 1" or any other constant to the SQL query.
(In reply to comment #145)
> It wouldn't be complex or confusing at all. You would just add "AND type = 1"
> or any other constant to the SQL query.

  Yes, that's more complex than it is now.
Comment on attachment 510220 [details] [diff] [review]
v4

>=== modified file 'Bugzilla/DB/Schema.pm'
>--- Bugzilla/DB/Schema.pm	2011-01-30 12:07:59 +0000
>+++ Bugzilla/DB/Schema.pm	2011-02-06 21:16:53 +0000
>@@ -1008,6 +1008,24 @@
>         ],
>     },
> 
>+    namedqueries_link_in_home => {

  Okay, yeah, looking at this now, I agree with LpSolit. We should do:

  user_id
  namedquery_id
  is_on_footer
  is_on_home

  All in one table, which should be renamed to:

  namedquery_subscription
  or maybe:
  namedquery_link_location

>=== modified file 'Bugzilla/Search/Saved.pm'
>+    link_in_home => \&_check_link_in_home,

  You can just do \&Bugzilla::Object::check_boolean.

> sub _check_name {
>     my $lif = delete $params->{link_in_footer};
>+    my $lii = delete $params->{link_in_home};

  Let's name that variable something more readable.

>@@ -259,6 +268,19 @@
>
>+sub link_in_home {
>+    my ($self, $user) = @_;
>+    # We only cache link_in_footer for the current Bugzilla->user.

  Nit: link_in_home.

>+    return $self->{link_in_home} if exists $self->{link_in_home} && !$user;
>+    my $user_id = $user ? $user->id : Bugzilla->user->id;

  Do we ever need to check that for a user who isn't the current user? If we don't, we shouldn't replicate this code from link_in_footer.

>=== modified file 'skins/standard/buglist.css'
>+
>+
>+body.simple {

  Could you put a comment above this like:

  /*****************/
  /* Simple Format */
  /*****************/

>=== modified file 'skins/standard/index.css'

  Similarly, you might want to section off the parts you added here, like:

  /**********************/
  /* Home Page Searches */
  /**********************/

>+    div.homepage_query_results{
>+      float: left;
>+      padding-right: 1em;
>+      white-space: none;

  What does white-space: none do?

>+    div.homepage_query_results iframe{

  Nit: space before {

>+        height: 40em;
>+        border: 0 solid transparent;

  Hmm, if we're going to limit the height, should they also have overflow?

>=== modified file 'template/en/default/global/field-descs.none.tmpl'
>-     "requestees.login_name"   => "Flag Requestee",
>+     "requestees_login_name"   => "Flag Requestee",

  This looks like a change that is unrelated to this patch.

>=== modified file 'template/en/default/index.html.tmpl'
>+          [% IF user.login %] 
>+              [% PROCESS show_searches %]
>           [% ELSE %]
>+            [% PROCESS show_welcome %]

  Cool, I like the simplicity here.

  However, I think that even logged-in users could use some links for the most-common actions, no? Perhaps they don't need the full-sized icons, though. (I will leave the decision on this whole thing up to your sense of HCI.)  

>+[% BLOCK show_searches %]
>+      [% homepage_queries.push( 
>+        { 
>+          name = "${q.name}"
>+          display_url = "buglist.cgi?columnlist=short_short_desc&query_based_on=${q.name}&list_id=${q.id}&format=simple&limit=50"

  You definitely don't want to include list_id in that URL. I suspect that it does not do what you think it does. Also, you're missing the sharer_id for shared queries.

  Also, I wonder if 50 is a bit high of a limit?

>+    display_url = "buglist.cgi?columnlist=short_short_desc&format=simple&quicksearch=OPEN+@${user.login_name}&limit=50"
>+    full_url = "buglist.cgi?quicksearch=OPEN+@${ user.login_name}"

  I'd rather not depend on Quicksearch as a stable API, if possible. resolution=---&assigned_to=%user% should do it. (That's a literal "%user%".)

>+  homepage_queries.push( {
>+    name = "${field_descs.reporter} is Me"
>+    display_url = "buglist.cgi?columnlist=short_short_desc&format=simple&quicksearch=OPEN+-@${user.login_name}+reporter:${user.login_name}&limit=50"
>+    full_url = "buglist.cgi?quicksearch=OPEN+-@${user.login_name}+reporter:${ user.login_name}"

  Is it possible to eliminate this code duplicate between full_url and display_url that all the searches have?

>+  <div style="clear:both">To add additional queries to your homepage <a href="userprefs.cgi?tab=saved-searches">click here</a>.

  Perhaps make the whole sentence a link with just the text "Add additional queries to your homepage."

>+  <tr><td colspan="4">

  Hmmm, should we eliminate this table?

>=== modified file 'userprefs.cgi'
>+                if ($cgi->param('force_home' . $q->id)) {

  I don't want people to be able to force others to have anything on their home page.
Attachment #510220 - Flags: review?(mkanat) → review-
Oh, also, I'd prefer not to have horizontal scrolling, since mouse wheels don't scroll horizontally.
BTW, I do see why you made that change about Flag Requestee. That's not a safe change to make without updating other areas, so we should avoid it if possible. Note also that if we do have that Requestee search, it should probably link to My Requests.
Target Milestone: Bugzilla 5.0 → Bugzilla 4.2
Oh, one other comment. If there is no order specified in the saved search, the bugs should be sorted in descending order of the date they were last changed.
Attachment #510220 - Flags: review?(LpSolit)
Target Milestone: Bugzilla 4.2 → Bugzilla 5.0
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

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 on time for 5.0.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0
I'm developing a modern Web app style Bugzilla client.
It's still at very early stage, but you may be interested in this:
https://www.facebook.com/pages/BzDeck/240285432763840
Assignee: guy.pyrzak → ui
Status: ASSIGNED → NEW
Some thoughts from roc that might be relevant: http://robert.ocallahan.org/2013/01/optimizing-bugzilla-usage.html
Target Milestone: Bugzilla 5.0 → ---
Attached image Bugzilla_Home_2002.jpg —

Just for context, this attachment shows how the front page presumably looked in 2002 (image is from the wayback machine)

Attachment #9347584 - Attachment is obsolete: true
Flags: needinfo?(ladaboy6969)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: