Closed (fixed)
Project:
Openlayers
Version:
7.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
10 Aug 2010 at 17:23 UTC
Updated:
9 Apr 2015 at 21:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
tmcw commentedThe module already lets you do this... by cloning any preset that's in code and editing it from there. Cloning with the same name = overriding.
Comment #2
davideads commentedGot it. Would it make sense to tweak the UI to make it more like that over other modules? Cloning with the same name doesn't exactly jump out at me as an obvious technique.
Comment #3
zzolo commentedHey @davideads. I agree, this is a common approach, given Views and Ctools, but I think there could be some usability improvements here. Any ideas?
* Is this something we put in the help on the presets list page?
* This could be a message on the preset form when cloning? (though probably too late)
* Also, this should apply to the other exportables.
Comment #4
davideads commentedZzolo -- what do you mean in terms of usability improvements? To the general CTools/Views model, or simply within OpenLayers?
Putting information in the help on the presets page would help...
A message on the preset form when cloning would indeed be "too late" in the sense that if the user doesn't know that they need to clone with the same name in the first place, and they haven't cloned/haven't read the clone form, then it doesn't help so much.
I'm totally behind being consistent in terms of other exportables.
I find the edit/revert UI that Views uses to be adequate, and plenty of people will understand it immediately.
Comment #5
zzolo commentedI am talking about improvements to our UI (not CTools). We are creating a UI on top of CTools architecture.
I don't have both in front of me, but this should all be very similar to how Views does this currently. All the terms are the same, basically.
Still, that doesn't mean we can't improve usability by being more complete in the help section on the Layers, Styles, and Presets lists page that describes the paradigm.
Comment #6
davideads commented@zzolo -- I just wasn't sure if you meant "go beyond" the Views UI in some way. I think the Views UI model makes sense: Every preset may be edited; if a preset that is also expressed in code is edited, then you can also "revert" it.
Comment #7
zzolo commentedSo, basically this issue comes down to changing the word "clone" for exportable objects in code to "Edit"? or possible "Override"? Any thoughts, anyone?
(moving to D7)
Comment #8
davideads commented@zzolo -- well, what I propose is to use the Views paradigm I described above -- the ability to edit/revert an exportable as well as clone it.
Comment #9
zzolo commentedSo, thinking about this a bit. The difference between OL and Views is in Clone. In Views, when you hit clone, it gives you a specific screen to change the name and ID. In OL, clone actually means Override or Clone. I am not sure how to best say this in the interface. This would be ideal (Export for all).
The problem is that making another step when hitting clone is significant work.
Thoughts?
Comment #10
zzolo commentedBumping to v3. We should actually be utilizing Ctools UI stuff for this anyway.
Comment #11
basvredelingThis is still relevant despite being 5 years old.
The only way I accomplished customisations right now is by exporting various presets and creating a custom module so I can override stuff in code.
The new 3.x branch needs a proper admin UI to edit and override maps, components etc.
This is a UI / UX project that we should tackle the same way the views redesign for D8 was tackled. For inspiration and references see:
I'm willing to dive into this.
Comment #12
polHello Bas,
You can override anything within Openlayers 3.x.
Could you please explain why you have to export presets to override them ?
Thanks.
Comment #13
basvredelingCurrently each and every entity overridable in 3.x only allows setting the name and description. Be it: maps, layers, controls, components, you name it. Als you can edit are name and description.
So, if you want to override something like the default zoom setting for the control zoom to source, you can't. Am I correct in assuming this still needs work?
Comment #14
polHello Bas,
No, you can configure a lot of options.
See the screenshots.
Comment #15
basvredelingThis is not how I experience 7.x-3.x or 7.x-3.0-beta1. I have non of these options available.
see screenshot. This is the meagre form I get in both admin display and in overlay / contextual links.
Comment #16
polClick on these links on the top !
Comment #17
basvredelingWait! What? That totally looks like a breadcrumb trail!
Thanks for pointing that out. I still think the UX needs a lot of work. So the offer of rethinking it still stands.
Comment #18
polThis is the default in many modules like Panels, Context, etc etc they are all based on the same UI: CTools Export UI and Form Wizard.
If you find this hard to find, you may help and tweak this class in the OL module, then submit a patch.
I will close for now the issue.
Comment #19
basvredelingOkay, I will open a new issue to improve the UI of openlayers / ctools.
The issue with the "wizard trail" on top is that it's a) not really clear this is a wizard, and b) this looks an awful lot like a buggy breadcrumb trail. Some browsing in the issue queue tells me I'm not the only one struggling with this: #1496514: Change wizard-trail style and remove " » " and #1775234: Local tasks on MiniPanels edit pages are confusing.
Comment #20
basvredelingPosted my gripes in #1496514: Change wizard-trail style and remove " » " will post a patch there too. Thanks for responding to this issue