-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Best place for third-party extension menu/settings? #1580
Comments
Couldn't agree more, there needs to be an official stance on this. Also running into this with m2 when going to Stores > Config and sort ordering of items (General tab should always be first, Advanced always last). There aren't any flags or notices raised when setting a new item to priority 1. I don't see a separate tab called Extensions anywhere unless I'm missing something. |
Thanks for this thread. Makes complete sense. I passed this thread on the UX team. We don't have written down guidelines today, but everyone agrees its a good idea to do so. |
Thanks @alankent. It also may be a good idea to correlate this to core code also which raises flags/notifications in the admin if the standards/guidelines aren't followed. This will force module devs to follow them, as no one likes seeing those notifications. |
I definitely think some best practice guidelines wouldn't hurt but I would also say that the overall scope of an extension needs to be considered as well. If we're talking about a simple additional feature such as a banner rotator there is no good reason to setup an entirely new menu option. However, if you're talking about a suite of tools which imparts major functionality/usability changes then I can see a situation where a separate menu might be warranted. Either way I see no reason that there should be any effort put into placing flags/notifications as I'm not a fan of restricting development to the limited scope that some developers might envision. That said perhaps providing store administrators with the ability to nest menu items to their liking would be an alternative. In this way if a developer creates a navigational structure which the store administrator finds to be a hinderance they can reorder it to meet their needs. |
I'l like to point out that this is also related to both ACL and general user experience: Banner Rotator for example has obvious place under CMS and so does Blog and few other things. Having tons of those vanity main menu items is extremely annoying as well. |
Now is the time to tackle this. We see many sites on 1.x that are just a total mess. I think defining clear standards now would be a good idea, its easy to see how these menus could end up a total mess. If you go for a set of guidelines you can always add/remove/refine later on, this is in beta after all. But get something out. Here are a few to consider, I'm not saying use these, just worth asking if should. Sure many more, just thinking out loud.
At WebShopApps we try to keep our impact on Magento admin to a minimum. We do have I think 1 extn that affects the top menu (Dropship) but in hindsight we should have put it elsewhere. If there was a sep apps menu I'd see stuff like that being a good fit (or even under a submenu in apps called Shipping) |
Hi all, great input above! The Magento DevDocs team is working on a Best Practices/Guidelines doc for extension developers, primarily around the issues of icons, menu items, and other tips/tricks/requests to help prevent Magento sites from "looking like a Christmas tree." We welcome advice like the above, and we are also working with the Beta program participants to solicit feedback on what could/should appear in the guidelines doc. Once we have collected enough to create a draft we will run it by Magento internal teams (marketing, product, etc) to get consensus, then it would be great if we could have some external reviewers. |
My two cents: The top level navigation "dashboard, sales, products, customers, etc" should not be added to by extension developers. Additionally I think these should match the top level navigation of the New Connect. So if a merchant installs an extension that is in the category products, the extension developer should add a submenu to products (if at all needed). I know there are use cases where nothing really fits into the existing top levels, however I think by aligning with the top levels in Connect it should become obvious which ones are missing (keeping the overall number down will only help the UX of Connect and the Magento back-end). These missing ones should get added by Magento with respective icons (and not be visible if nothing is in them). The top one that comes to mind is integrations (currently there is one entry under systems but it is very narrow in focus - should probably be renamed to Oauth Integrations) which would cover a lot of reasons top level menu entries have been created (including us) in the past. Equally some alignment of the settings section with the top level navigation would help a lot in the navigation experience: A couple of suggestions here where consistency could be improved: In general I'd suggest to align the sections of the configuration with the top level navigation as well. This in turn will also make it a lot easier for extension developers to add their settings in the most fitting place. |
I also recommend tadding a new top level menu item "Developers" for tools related to site development (such as where you allow IP addresses for development mode and so on). |
@wsakaren, @pronto2000, and @fooman, thanks for the lists and the real world example. DevDocs has started the Best Practices Guide, and we are adding candidates for evolving Best Practice guidelines around. As soon as we have the draft in good enough shape to share, we'd like to push it our devdocs repo (github.com/magento/devdocs) and request the community's feedback/contributions/etc. Thank you all! |
@tanberry how is it going? Did you come with any guidelines? |
Hi @wojtekn. Funny you should ask; this project has (thankfully) been revived, just yesterday! DevDocs is working with the UX team and Engineering and of course @benmarks et al to help craft a starting set of guidelines, in the form of a FAQ. Goal is to publish those basic ones in next couple of weeks, and then get community to add Questions (and proposed Answers); internal teams will then add the "official" answers. Thanks for your patience, and we look forward to your help in maturing the guidelines. |
Hi @ikk0, thanks for that [not so beautiful] example. We agree, we don't want a mess to be made of the Admin's primary navigation. I'm happy to say that we finally have the first draft/proposal of the Best Practices Guide available! (Thanks for your patience, @wojtekn and everyone!) We just published it last weekend, and are requesting feedback from the community. In the Introduction page you'll see a link to a .md file that we created specifically for gathering feedback, but please also feel free to email myself at [email protected] or my writer colleague James at [email protected] with any feedback you have! We collected quite a bit of feedback at Imagine earlier this week, and we will be integrating that feedback in the next few weeks. |
The contributor guide suggests that tickets that have not been active for two weeks should be closed. |
I have wonderful news for this thread. We just released an opensource Magento 2 extension that will wrap all the 3rd party extension menu items to a common menu item named "Extensions". It can be found here https://github.com/redchamps/clean-admin-menu |
This issue has been brought up many times.. It concerns extension developers adding their own tabs/menus to the admin panel in Magento.
Opinions split: some developers are strongly against it https://twitter.com/fschmengler/status/587874924653580289,
while others believe it might be easier this way for non-tech-savvy users to find the settings for a particular extension https://www.reddit.com/r/Magento/comments/32jkn4/dear_extension_developers_your_menu_is_not_that/
Does Magento have an official stance on this? It looks like in Magento 2.0 all such menus will be in a separate tab called "Extensions “. Does this mean each extension will have its own tab there?
On a side note, it would be nice to see Magento come up with a clear set of recommendations for all developers to follow. This way, third-party extension tabs/menus/settings would become more uniform, which would be great for the end user of said extensions.
The text was updated successfully, but these errors were encountered: