[Plone-UI] Dexterity UX notes from Emerald Sprint
djay at pretaweb.com
Thu Feb 21 23:49:04 UTC 2013
On 20/02/2013, at 6:58 AM, Alice UXAccount <atseng.ux at gmail.com> wrote:
> oops forgive the double reply, forgot to reply all.
> On Tue, Feb 19, 2013 at 11:54 AM, Alice UXAccount <atseng.ux at gmail.com> wrote:
> Hi Dylan,
> Thanks for your thoughts and feedback.
>> We should be thinking about the future where TTW developers outnumber file-system developers 2-3 times.
>> As such we need to be careful about relying on surveys of existing developers. We are very different people that those that I train to use diazo and dexterity TTW.
> 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 that it will be useful to survey a few groups just to get a better understanding of potential audiences, but to clarify, these surveys wouldn't be used as a narrow directive in anyway (and certainly not to skew the interface into an audience group that currently doesn't use the tool at the cost of another).
> As with most of these techniques they aim to facilitate a wider discussion and to provide a more holistic approach at looking at the problem space. Indeed, I would suspect that "TTW Developers" think about things differently than "File System Developers" ... but in which ways and how ... I think surveying could get us some useful information.
> For example, we could survey existing file-system developers for the types of tools they currently use in their workflow for rapid prototyping and communicating with non-developers and get some insights into which type of features and tools they find valuable and which they don't.
> This type of survey may indeed prove that the TTW editor has no potential for this specific audience but it may uncover some features that actually are a good fit; at the very least it would provide useful information for framework developers on what this audience is already using/has unmet needs in (for rapid prototyping/communication) that may benefit the overall framework.
>> One way around this is we could have a new kind of behaviours. A field set. It's like a behaviour in that you can reuse it amoung many content types. The difference is it only does one thing, and thats and a single block of fields to a certain location in the schema. So it's a reusable mini schema. They could be editable via the web, and once you edit them, the changes are reflected in any content type that uses that fieldset. Plone could come preinstalled with many fieldsets such as "dates" "contributors" "events" etc.
> This notion of some type of "common presets" was a theme I saw come up several times during the Sprint - some folks mentioned the 80% most common cases, others use the language of 'templates" -- but there seems to be some convergence on the idea that some common behaviors or fields could be pre-bundled and re-usable to save users' time/effort.
I was more getting at making a subset of behaviours visual. You can't make behaviours across the board visual since their semantics mean they can do anything. But most of the predefined behaviours do the same thing, that is "insert a set of related fields into one place in the schema". If there was a way of TTW schema editor knowing which behaviours did this, then there could be a much nicer UI which let you drag and drop that field set into the schema, at a location you choose. You can see which fields it inserted without having to go add an instance of that type (which is what you have to do now).
I then took that a step further and said you could make those fieldsets editable online. e.g. the "dublin-core metadata" fieldset could be edited to add a new field "review date" and across the board all types that used that fieldset would now have that field.
I'm not sure if that corresponds with your idea of templates and reuse or not.
> An interesting ah-ha when the group was brainstorming is the issue that having saved re-usable bundles would mean that the user should be able to select which ones are active. Then, everyone realized that this would be a useful feature now -- even without presets -- currently the moment you create a content type it's automatically activated in the site.
>> We're prepared to try and involve some of our customers who we're encouraging to use dexterity in this kind of testing. That isn't many people because you can't really do much with TTW dexterity right now (unlike diazo).
> That would be great and very helpful. You don't need a ton of users - in fact every user you observe and get feedback from adds to the collective understanding of the problems and solutions. Let me know if you need any resources to facilitate that.
Most users we give diazo. One customer wanted a custom bulletin type, so we gave them dexterity. They created most of the fields ok but then got stuck when they wanted interrelationships between fields, for example picking "update" from one field enabled entering data into another field that was previous disabled. Not something that can be done ttw. The big downside is we had to reimplement the type in FS code and now they can't change any of the schema anymore without asking us or learning FS development. It's a resonable thing for them to want to add a field to this type even if it's FS code, or change a default or change a description or change a vocabulary. I'm not sure how we can solve this one easily.
More information about the UI