[Plone-UI] Dexterity UX notes from Emerald Sprint

Alice UXAccount atseng.ux at gmail.com
Wed Feb 27 18:48:31 UTC 2013

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

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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-ui/attachments/20130227/447bf642/attachment.html>

More information about the UI mailing list