Redmine

About adding wiki pages.
Now, when adding an wiki page, it is known which wiki page is is its parent. How do you plan to deal with this?

Ivan Cenov wrote:

Now, when adding an wiki page, it is known which wiki page is is its parent. How do you plan to deal with this?

You can actually add wiki pages without specifying a parent, just try /projects/<your project>/wiki/<something>. You could even select the parent from a dropdown if you like, but it is not mandatory. What you need though is a name, but that could be added as an additional field in the new wiki page form...

Jan Niggemann (redmine.org team member) wrote:

I re-set this to new, please test and merge this.

Oh, I only saw this comment now. Sorry for not responding earlier. Not sure who it was directed to.

I think, I don't have commit rights, so I'd be more than happy if anyone who does would take on merging this in.

jan jan (from Planio), it is very interesting.
Could you please share new patches compatible with latest trunk?

Go MAEDA wrote:

jan jan (from Planio), it is very interesting.
Could you please share new patches compatible with latest trunk?

Sure. Do we have consensus that we want this committed into trunk, though? If not, I'd rather wait until we do before I rebase them. I think it would be more efficient this way...

If you want to have a look at it first, I'd suggest you apply them to the then-current trunk when I submitted them or create a demo account at Planio where this runs in production for ~2 years now.

Mischa The Evil: are you still reviewing this btw, or should I remove you as assignee?

Go MAEDA wrote:

To spark up some discussion, I am setting the target version to 3.3.0.

That sounds great to me. Let's wait for some other contributors to voice their opinion. If everyone wants this for 3.3.0, I will be happy to rebase it and prepare for a merge.

I'm not a contributor, but I like the patch (especially for new wiki page button). +1 from me.

I haven't tried the patch yet or used plan.io to test it, but in my case, "normal" users would just see a single "New Issue" dropdown entry when clicking the "+" icon in the menu as they are not allowed to create new milestones or categories and wiki is disabled for the project. I wouldn't call this an improvement over the current UX design in my situation...

Let me add another point to the discussion: I understand that UX improvements are important and this might look good, but the "New Issue" tab has always been a very prominent step for non-tech users to quickly report bugs / feature requests / etc and many third-party-themes highlight this tab as well. I have mixed feelings about hiding this menu item, also in terms of accessibility...

Tobias Fischer wrote:

I haven't tried the patch yet or used plan.io to test it

Try it, maybe you'll think about it differently ;-)

but in my case, "normal" users would just see a single "New Issue" dropdown entry when clicking the "+" icon in the menu

No need to click as it will open on hover already. It's thus just a different move with the cursor when compared to the old "new issue" tab – no additional "click work" required.

as they are not allowed to create new milestones or categories and wiki is disabled for the project. I wouldn't call this an improvement over the current UX design in my situation...

Maybe not an improvement in this situation, but it doesn't make UX worse in my opinion, either. For other cases (where users do have more permissions, which is the default, btw.) it will certainly make creating content more consistent.

I tried this feature on plan.io and it's great.

Jan from Planio www.plan.io wrote:

Tobias Fischer wrote:

but in my case, "normal" users would just see a single "New Issue" dropdown entry when clicking the "+" icon in the menu

No need to click as it will open on hover already. It's thus just a different move with the cursor when compared to the old "new issue" tab – no additional "click work" required.

For the case described by Tobias, I think that a minor improvement is to have the "new issue" action also for click on "+" icon. In this way, the users can add a new issue from one click, without the additional small steps (hovering and selecting the New issue from the dropdown).

Marius Balteanu wrote:

For the case described by Tobias, I think that a minor improvement is to have the "new issue" action also for click on "+" icon. In this way, the users can add a new issue from one click, without the additional small steps (hovering and selecting the New issue from the dropdown).

This could be a way to solve the issue.
But still, I'd say this is bad UI/UX as there is just a "+" sign and the user has to figure out by himself, what's behind it.

Also bad UX in terms of accessibility.
Andy ideas how to solve this?

And what about support for third-party themes which use a vertical nav menu? Would the HTML structure still allow for such a design change?

The "+" button is OK but I would not remove "New Issue" from the menu, at least not yet. Our users are very used to it and such change would make a lot of concern. I would recommend to keep "New Issue" in few places until everyone gets used to. At the same time #6658 sould be implemented.

When implementing any major UI changes, it's generally a safe idea to create the new UI code and set it as default, with an associated option in the UI configuration to "revert to old behaviour".. Wouldn't that solve a number of [potential] issues?

At the same time, I agree with Tobias' opinion above: using an icon in a word-based UI is generally a bad idea.. If it were an icon-base interface, then it might be different, but in the current instance words are definitely a better fit.

After r15344, we have to click 2 times ("Issues" -> "New issue") to create a new issue if our browser shows other than issues list. It can be resolved by implementing this feature. Please implement this feature.

jan jan, could you provide an updated patch?

Tobias Fischer wrote:

Marius Balteanu wrote:

For the case described by Tobias, I think that a minor improvement is to have the "new issue" action also for click on "+" icon. In this way, the users can add a new issue from one click, without the additional small steps (hovering and selecting the New issue from the dropdown).

This could be a way to solve the issue.
But still, I'd say this is bad UI/UX as there is just a "+" sign and the user has to figure out by himself, what's behind it.

Also bad UX in terms of accessibility.
Andy ideas how to solve this?

And what about support for third-party themes which use a vertical nav menu? Would the HTML structure still allow for such a design change?

Speaking of vertical nav menus, how would this "add new" menu work when on mobile devices, with the responsive stuff?

If it's a separate popup/hover menu of its own, then on touchscreen devices, the first touch would open the menu, so it would still be two actions to start a new issue. Unless there's some kind of special case that overrides that for touch.

If it just spills everything out onto the hamburger menu, then still two actions.

But anything else then starts taking up valuable real estate.

Jean-Philippe Lang wrote:

"New issue" tab is removed (but I guess I have to provide a way to restore it anyway)

I strongly agree.
I think "New issue" tab should be placed in project menu if this new "Add" button is not implemented.

Tobias Fischer wrote:

Also bad UX in terms of accessibility.
Andy ideas how to solve this?

Btw., I have moved the access keys to the (always visible) "new issue" link within the "+" menu. This way, the Ctrl+Alt+7 shortcut will work even if the "New issue" tab is disabled in the settings.

Furthermore, the "+" menu is designed to work on devices with a mouse (on hover) as well as on devices with a touchscreen (on click).

the fury wrote:

Speaking of vertical nav menus, how would this "add new" menu work when on mobile devices, with the responsive stuff?

The "+" menu does not show in the responsive menu (yet). However, with the "New issue" tab being optional, I would say that already committing the "+" menu is an improvement even without a responsive version for it since it doesn't remove anything. It just doesn't add anything for the responsive mode. It would be great to add responsive support at a later point in time if anyone has a good idea.

Go MAEDA wrote:

I suggest making a small change to "+" button. "This patch" (15880-add-link-to-new-issue.diff) adds link to /issues/new page to plus button. Users can access to the page quickly like conventional "New issue" tab, only by clicking "+" button.

Comparison of steps to access "/issues/new" page:

Current implementation:

1. Move cursor to "+". Dropdown menu shows up.
2. Move cursor to "New issue" menu item.
3. Click left button of a mouse.

After the patch (15880-add-link-to-new-issue.diff) applied:

1. Move cursor to "+".
2. Click left button of a mouse.

Jean-Philippe Lang wrote:

Yes, that's why I'm not really convinced of this new menu item. Anyway, it's merged into 3.3, with a setting to choose whether to use the new "+" (default), the old "New issue" tab or nothing.

Can we get a setting to show both "+" and "New issue" tab? It would be easier to introduce this menu change to users and give them a time before turning "New issue" tab to learn/adjust.

What about a split button with a "current page default" and a drop-down menu in one?

Working from the current behaviour in 3.3, the primary idea is to change the current "+" button to a dynamic button, showing "New <type>" based on the currently viewed page. So, while viewing the "Issues" page, this would be "New Issue", "Roadmap" would be "New Version", etc. The right-side of the split button would be a small area with a down arrow, which would open the drop-down menu with all the current options.

This would provide consistent and predictable behaviour across all platforms regardless of input type or screen size, and it would make keyboard navigation easier while tabbing through links on the current page (yes, some people still use that on web pages).

I'm no Ruby guru, but I do love working with HTML/JS.. So I should be able to get the latest version up and running on my side and make a patch for this idea, if need be?

[edit] My apologies, I only noticed after my comment that this issue had been closed... I'm at work at the moment, so unless someone else likes this idea and beats me to it, as soon as I get a chance I'll make a patch for the changes I proposed and open a new ticket for discussion.

Redmine administrator Greeff: That is a good idea! I also thought about something like this, but without thinking about a solution: It's very likely that I'd like to create a new version if I'm in the version section - and less likely that I then would like to create a new wiki page. If this not already considered in an own ticket you should create a new one. It may goes into version 3.3.0 to make the global button more attractive straight from the beginning.

Yes, please create a new ticket for this. This one has been closed and it's not likely many will see the discussion here.

Hi,
With Display "+" menu settings,
The + is visible in the project page.. But when I click on that + nothing happens.. The menu is not shown..

Using the latest commit in master.
I checked in both Chrome (Version 51.0.2704.84 m) and Firefox (47.0).

Thanks.

Could you please post a little more about your environment? See Submissions for info on what to include. Please also mention your theme and where exactly this situation happens. You mention the "project page", do you mean /projects?

Thanks!

Jan from Planio www.plan.io wrote:

Tobias Fischer wrote:

And what about support for third-party themes which use a vertical nav menu?

I am not aware of any currently-supported themes with vertical project nav.

The "Highrise" theme for example (optionally) uses vertical navigation:
http://www.redmine.org/projects/redmine/wiki/Theme_List#Highrise-theme
https://www.redminecrm.com/pages/highrise-theme

The theme is under active maintenance so I think they will figure out a way to go with the new + button...