On 30/09/13 07:14, Ryan Ollos wrote:
On Fri, Sep 27, 2013 at 8:53 AM, Olemis Lang <[email protected]> wrote:
On 9/27/13, Ryan Ollos <[email protected]> wrote:
On Thu, Sep 26, 2013 at 1:08 PM, Olemis Lang <[email protected]> wrote:
On 9/26/13, Ryan Ollos <[email protected]> wrote:
On Tue, Sep 24, 2013 at 11:29 PM, Apache Bloodhound <
[email protected]> wrote:
[...]
Btw, how does one navigate to the product view
`/products/<product>/products/<product>`? It doesn't seem to be linked
from
anywhere, at least in a default configuration. Shouldn't it be linked
from
the product list page `/products`?
AFAICT products list page (both global and local) are not linked from
anywhere else (cmiiw) . AFAICR there was a main nav once upon a time
... prior to bep 3 and latest theme implementations .
I propose we do the following:
- Link the Product list page (`/products`) from somewhere that is always
visible (mainnav would be the most obvious choice).
+
So should be just add a "Products" to the mainnav? I don't have a better
idea, and it seems like a good enough choice (#678).
I'm not actually all that keen to add more to the default mainnav. I was
thinking that it might be better to provide a more uniform breadcrumb
across all views. We already have the ability to select products from
various ticket related pages and this has the All products link to the
products page. How would people feel if we also had this product
dropdown available for wiki pages, for example?
We may also want to consider whether changing the product with that
dropdown control should always go to the product home (default_handler)
or if it should depend on context (i.e. go to the /products/<pre2>/wiki
or /products/<pre2>/dashboard when selecting product from a <pre1> wiki
page or ticket page respectively.)
> - From the produce list page, link to `product_view.html` for each
product.
It's the Dashboard . The fact is that the default product URL
namespace overlaps with product_view.html in global scope but not in
product scope . Therefore , in order to provide a consistent
navigation in all contexts . Indeed /product_view.html is a kind of
dashboard too .
In the case of sub-domain deployments that overlapping does not exist
, that's why I noticed these issues ;)
Maybe the //Home// button should direct there?
IMO the home button should point at the product home page , usually
the wiki but maybe other page in the web site depending on
configuration .
Yeah, it makes sense to have Home direct to the default_handler.
If there is to be a home link then, yes, this would probably make the
most sense. There seems to be potential for a bit of overlap of links
though..
Thoughts?
I'd rather advocate inserting a new nav item e.g. View pointing at
$product_base_url/products/<prefix> which would be expanded to
/products/<prefix>/products/<prefix> in default install or
<prefix>.dom.ain/products/<prefix> for sub-domains (... or the
corresponding path if other URL namespace is deployed ;)
Items would look like this ...
View | Edit | Home | Tickets | Wiki
[...]
Adding a View link sounds good. I think it would be good to do this for
Release 8 since you've already made so many improvements to the Product
List page (#677). I'll plan to work the ticket if you don't beat me to it!
Actually, I think things may be going a bit strange here. Do we really
need both
*
/products/<prefix>/products/<prefix>
*
/products/<prefix>/dashboard
Apart from being a little confusing, there is significant overlap with
the product page adding some details about the product and the ability
to edit or delete. Would it be worth unifying these pages? Is there a
reason that we don't want the product information on the dashboard page?
Unification would make the View link redundant which may be a good thing.
I also note that, at this point we have four links per row that be
default show exactly the same page: the product icon, home and browse
links all go to /products/<prefix> and these show the same view as
/products/<prefix>/wiki. That is a whole lot of redundancy.
Cheers,
Gary
