[Plone-UI] Dexterity UX notes from Emerald Sprint
djay at pretaweb.com
Wed Feb 27 21:59:45 UTC 2013
On 28/02/2013, at 5:48 AM, Alice UXAccount <atseng.ux at gmail.com> wrote:
> Hi Dylan,
> > This is an interesting point -- would you segment the "TTW Developer" as a unique group or would you see them as sharing similar goals as "webmaster / integrator" ?
> Not really. as an example we run a SaaS platform similar to ploud.net. Our customers can do anything they want TTW but can't deploy plugins. We'll only deploy thirdparty open source plugins that benefit everyone on the platform because once a plugin is deployed it's shared by everyone. Since these users have no option of using FS code then it's not for prototyping, it for creating real functionality on their site. This is one kind of group. They aren't webmasters I think because I associate webmasters with ftp or ssh access. They are a kind of TTW integrator.
> When we develop themes or code for them, we want to do it in a way that they can use that and modify it for themselves later. For that reason we deliver dexterity or daizo as web modifiable rather than as FS code. So we're integrators that could do FS development but choose not to. But we don't use the diazo online editor for example, just upload it as a zip file in the end.
> I think a third group is those who download Plone, run it locally and want a quick way to get started. The more capable we make Plone without them having to learn python, templar, zpt etc, the more happy they are and the more they recommend Plone to their friends :)
> The problem is none of these three groups exist in any great numbers today I believe. It's a "build it and they will come" type hypothesis.
> I think you bring up some interesting audience segments to keep a watch on. And I think there may actually be more users like what you've described existing, than have been identified. For example, at the University environment I saw what you're describing -- the "TTW Developer" as a distinct audience quite often from the Diazo perspective and possibly from the Dexterity perspective as well (need was there but a solution didn't exist yet).
> 2 cases where users only had TTW options:
> 1. "Web designers/developers" working within a university department are often responsible for many of the features (not just theming but integrating 3rd party products) for their unit sites. However, the structural hierarchy is that the department IT group handels the server administration and thus the "unit web designers/developers" have no access to the file system. They have to respond to their stakeholder needs for changes but they have to issue any FS changes as requests to the server admin -- often the stakeholder needs are out of sync with the priorities of the department IT group's timelines for system updates; this creates timing conflicts between stakeholders, unit web designers/developers, and the department IT. Both from the department IT group and unit web designer group there would be gains if more could be done TTW by the unit web designers/developers.
> 2. From the perspective of University central IT -- a group I was working with was implementing a similar SaaS platform solution to what you describe. And since it would be providing a platform, the individual needs of the clients and their ongoing customizations for small specific tweaks is something that needs to be accomplished TTW. However, in this second case, the "TTW integrator" would be a non-technical "site manager" type as the reason they would be using the SaaS platform is because they didn't have the budget for a full-time web designer/developer on staff.
> From the university context I see both patterns happening a lot -- the issue is that the people who have domaine over the file-system are often not the same who are responsible for the day-to-day look & feel of specific sites; "TTW site managers" and "TTW developers" in these situations are indeed not the "webmaster" in the classical sense.
> As the web has become more sophisticated, these folks have pressure from their stakeholders to provide much more than theming changes. The other issue is that while the developer group is technically savvy, they are not python proficient or familiar with Zope and thus the ZMI is not a viable mechanism for them.
> As you mentioned, what I've witnessed, the "TTW Developer" group doesn't really tend to use TTW for the sake of GUIs; they tend to be quite technically savvy (many are experienced web developers) and they tend to want more "ability" and "efficiency"; their main issue is that they do not have permission to hit the FS and they need to make changes and all of them seem to get very frustrated via the ZMI since it comes with a bigger overhead than they feel value gained.
> I think this does paint a more complex story of who the TTW are for -- but I also think its good to consider this. Looks like there are non-technical users who are in need of a GUI for specific needs (site manager types) and another group who are technical but have no access to making changes unless it was TTW, since they are locked out to file-system changes, who have needs for other issues.
> I actually have seen both cases within the same department -- and noticed that the "non-technical site manager user" gets very frustrated with tech jargon and cryptic power functions while the "TTW integrator" gets frustrated with not being able to do enough -- I'm wondering if there are ways to better distinguish the needs for the 2 groups and perhaps discover some opportunities to meet unmet needs.
> If I were to spend time crafting a needs assessment survey, would you be willing to pass some along to your users?
After reading your further elaboration of TTW developers vs admins it made me realise something we've been struggling with.
One of the things we're doing is trying to allow TTW developers to do more. One attempt at that is listingviews (https://pypi.python.org/pypi/collective.listingviews).
When writing it, the easiest way to build the UI was using a control panel configlet and to store its configuration is in the settings registry. However it's tightly connected the current diazo theme, and it's the TTW developers who modify it, not the same person who is adding and removing users etc. This has always bothered me but I'm not sure how to solve it. I don't want admins going in there and accidentally removing a view and breaking the site. It should be something their frontend developer develops in staging, migrates to production at exactly the same time as the diazo theme (and perhaps dexterity types) and is clearly marked for admins not to touch or restricted by permissions.
The same is true of styles in the tinyMCE configlet and some other settings. Dexterity and workflow is also more development orientated
It's making me think that maybe we need some way divide up the control panel between the developers and admin?
A related issue is that anything more developer related needs to be imported, exported and moved between staging, production and development etc. Perhaps if the configuration of those settings was clearly separated from the admin type settings we could have some similar zip type import/export format?
More information about the UI