Plone
This is here to serve as contents for the atom/rss feed for Plone, also read by planet.plone.org.
zest.releaser 4.0: major update
zest.releaser has a fresh 4.0 release, with some nice improvements. So, what's new?
zest.releaser 4.0 has various improvements. We have better errors and warnings, did some cleanup, added little tricks, and have a recommended list of extra packages to use in combination with zest.releaser: check-manifest, pyroma, wheel, and twine.
Main improvements
Errors and warnings
We are better at showing errors. This is especially true for errors when uploading to PyPI. They were unintentionally swallowed before, so you did not notice when an upload failed. Oops, sorry about that.
Errors and warnings are more noticeable, because we colorize them. Errors are red, warnings are magenta. We use the colorama package for this.
We not only do this for lines that are printed explicitly by zest.releaser itself, but try to do this also for output from programs that we call, like check-manifest and python setup.py. This is a bit tricky though. Program should print standard messages to the standard output file and errors and warnings to the standard error file. Not all do that. So we might be missing some colors.
We allow retrying some commands when there is an error. Currently this is only done for commands that talk to PyPI or another package index. We ask the user if she wants to retry: Yes, no, quit. If for example PyPI upload fails because you have the wrong credentials in your ~/.pypirc, you can edit this file and tell zest.releaser to retry the command.
Cleanup
Python 2.6 is not officially supported anymore. It will probably still work, but we are no longer testing against it, so issues may start creeping in. This says nothing about the packages that are created: zest.releaser on Python 2.7 is still perfectly capable of creating distributions for older Python versions. Or for Python 3.
Sorry, zest.releaser itself does not run on Python 3. At least I have not tried it, and certainly the tests will be a pain to fix for both 2 and 3.
We have removed code for support of collective.sdist. That package was a backport from distutils for Python 2.5 and earlier, which we do not support.
Little tricks
We do not accept y or n as answer for a new version. I saw that with a few packages, which seems an obvious mistake.
When doing a postrelease, we add a always edit the changelog file to get a new version section with the text '- Nothing changed yet'. Now, when you do a prerelease and no real changelog entry has been added, so the text is still there, we warn and ask if you really want a new release. Probably you want to stop, check your version control history, and add one or more proper changelog entries.
zest.releaser makes commits in the prerelease and postrelease phase. Something like Preparing release 1.0 and Back to development: 1.1. You can add extra text to these messages by configuration in your setup.cfg or global ~/.pypirc.
One nice use case for this is telling Travis or Jenkins to skip Continuous Integration builds, like this:
[zest.releaser] extra-message = [ci skip]
This depends on how your testing server is setup. It might not have this enabled, or it might be looking for a different message.
Of course, you can also add your favorite geeky quotes there:
[zest.releaser] extra-message = No one expects the Spanish inquisition! So long and thanks for all the fish.
recommended extra
We have a list of recommended extra packages that we think are helpful for most users of zest.releaser. This is in the zest.releaser[recommended] extra. So if you use pip, you can install those like this:
pip install zest.releaser[recommended]
With buildout, you would use a section like this:
[script] recipe = zc.recipe.egg dependent-scripts = true eggs = zest.releaser[recommended]
What is currently in this list? We have check-manifest, pyroma, wheel, and twine.
check-manifest
This checks if the distribution that zest.releaser will create of your package contains all the files that you expect to be there. In some cases your setup.py will contain enough information for Python to include the correct files. Or you rely on a helper like setuptools-git, but then you miss files when someone else who does not have this helper package makes the next release. So in a lot of cases you will want to use a MANIFEST.in file. As an example, zest.releaser itself currently has this:
recursive-include zest * recursive-include doc * include * exclude .installed.cfg global-exclude *.pyc
You can run check-manifest as a standalone command. When used in combination with zest.releaser, the prerelease part calls the check-manifest command for you. That may look like this:
$ fullrelease INFO: Starting prerelease. Do you want to run check-manifest? (Y/n)? listing source files under version control: 6 files and directories building an sdist: mauritstestpackage-0.2.dev0.tar.gz: 6 files and directories copying source files to a temporary directory building a clean sdist: mauritstestpackage-0.2.dev0.tar.gz: 5 files and directories files in version control do not match the sdist! missing from sdist: CHANGES.rst suggested MANIFEST.in rules: include *.rst MANIFEST.in is not in order. Do you want to continue despite that? (y/N)?
check-manifest may report some files as missing from the source distribution where you know this is fine. You can tell check-manifest to ignore those by adding a setup.cfg file next to your setup.py. ``zest.releaser`` itself currently has this:
[check-manifest] ignore = doc/build doc/build/*
We could add some more there, like bootstrap.py, buildout.cfg, and .travis.yml.
For more info on check-manifest, see its PyPI page: https://pypi.python.org/pypi/check-manifest
pyroma
This does various checks on your package. Most of them are about your setup.py. This results in a rating between zero (bad) and ten (good). The rating is also given with the name of a cheese. If your package 'smells' good, you get a better cheese. Where does the name of the package come from? It checks the aroma of your package: Python + aroma = pyroma.
You can run pyroma as a standalone command. When used in combination with zest.releaser, the prerelease part calls the pyroma command for you. That may look like this:
$ fullrelease INFO: Starting prerelease. Do you want to run check-manifest? (Y/n)? n Run pyroma on the package before tagging? (Y/n)? INFO: ------------------------------ INFO: Checking /Users/mauritsvanrees/own/mauritstestpackage INFO: Found mauritstestpackage INFO: ------------------------------ INFO: Your package does not have classifiers data. INFO: You should specify what Python versions you support. INFO: Your package does not have keywords data. INFO: Your package does not have author_email data. INFO: Setuptools and Distribute support running tests. By specifying a test suite, it's easy to find and run tests both for automated tools and humans. INFO: ------------------------------ INFO: Final rating: 6/10 INFO: Compté INFO: ------------------------------ Continue? (Y/n)? n
For more info on pyroma, see its PyPI page: https://pypi.python.org/pypi/pyroma
wheel
There are various package formats for Python. Until now, zest.releaser was only doing source distributions, by calling python setup.py sdist. We still do this. Note that we have never released binary eggs (bdist_egg).
wheels are the shiny new Python package distribution format. zest.releaser 4.0 supports creating them and pushing them to PyPI.
Should you want this? Maybe. See http://pythonwheels.com for deciding whether this is a good idea for your package. Briefly, if it is a pure Python 2 or pure Python 3 package: just do it.
Also, if you are using buildout: sorry, buildout currently (2.3.1) does not support wheels. It is fine to create them, but you should still create a source distribution as well. zest.releaser does that, like it always has.
Say you want zest.releaser to create a wheel. How do you do this? You add a setup.cfg file in the top level directory of your package, so next to setup.py:
[zest.releaser] create-wheel = yes
Or if you know you want this for all your packages, you can also do this globally by adding the same text in your ~/.pypirc.
zest.releaser then takes care of the rest: when releasing, it creates a plain old source distribution and a shiny new wheel and uploads them to the package index.
For more info on wheel, see its PyPI page: https://pypi.python.org/pypi/wheel
twine
Since version 4.0, we prefer twine for uploading to the Python Package Index, because it is safer: it uses https for uploading. If the twine command is available, it is used for uploading to PyPI.
Note that we call the twine command directly. If the twine command is not available, you may need to change your system PATH. In the case of buildout, you may need to say dependent-scripts = true in the section where you add the zest.releaser[recommended] egg.
How does it look? When I used zest.releaser to release itself, it looked like this:
INFO: This package is registered on PyPI. Register and upload to pypi (Y/n)? INFO: Running: twine upload dist/* -r pypi Uploading distributions to https://pypi.python.org/pypi Uploading zest.releaser-4.0-py2-none-any.whl Uploading zest.releaser-4.0.tar.gz
When your package is not registered yet on PyPI, twine will currently fail. So you have to register the package manually. Use your browser to login at PyPI and then use the package registration form.
We could consider letting zest.releaser call the old-style python setup.py register instead, or ask the user. If you have thoughts about this, you can use our issue tracker to start a discussion.
As an aside, did you know that there is a test website for the Python Package Index? You can use this for making test releases of packages. If you want to take zest.releaser for a test run and do not want to publish your package on the real PyPI yet, you can release to https://testpypi.python.org. Edit your ~/.pypirc file to something like this:
[distutils] index-servers = pypi testpypi [pypi] # default repository: https://pypi.python.org/pypi username:maurits password:secret [testpypi] repository:https://testpypi.python.org/pypi username:maurits password:secret
Then when running our fullrelease or release command, answer 'no' when zest.releaser asks if you want to upload to pypi and answer 'yes' when asked to upload to testpypi.
For more info on twine, see its PyPI page: https://pypi.python.org/pypi/twine
That's it. I hope you enjoyed reading about the improvements. Now go use it! Get it with pip install zest.releaser or pip install zest.releaser[recommended] at https://pypi.python.org/pypi/ or read more at http://zestreleaser.readthedocs.org
PLOG Friday evening report-out
Report-out of the sessions of today, and general report-out (executive super small summary) of the week, at Plone Open Garden Sorrento.
Report-out of today
- Some cleanup tasks for the future identified, fifteen to twenty. Made list of benefits connected to each task. Like: pep8, remove skins usage from core Plone. Risks. Probably setup web page for people or companies to donate money to spend on cleanup, bit like Plone Intranet Consortium. Workers that work for, for example, half the normal wage. Because these are mostly boring tasks, that no one really wants to pick up, not very rewarding of its own. Individual, or group who organises itself. Sponsor can pay you as normal. Do not set up a big organisation. Trust each other.
- Through the web customization, without being horrible. Looked at collective.jbot. Some security issues that need to be considered. That package needs Plone 5 support. ACE editor is useful. Resource folder to add. jbot folder in your diazo theme. Advertise as add-on, not in core, as the approved way to allow these kinds of hacks, with round-tripping. Maybe move to core in the end.
- Increase number of Asian Canadians in Plone. :-) So: diversity meeting. Some are under represented. White males dominate the Plone scene, or at least at the PLOG. But there are some families here, which is very good. Non-native English speakers should feel welcome. At future events, we ask you to look at for newcomers. Connect new people with old-timers. Prioritize first-time speakers at events, help and encourage them. Expand range of talks, like how to run a small business, be a free-lancer. Simple things to make ourselves more attractive to new people.
- Documentation. Explained how we do it.
- Trainings. Three people are willing to give a training at the next conference. Fulvio, Fred, Philip. Beginner, integrator, developer. Master class maybe? Training the trainers. Enable new trainers, tips and tricks, how to set it up and market it. So: we are going to have a Plone Training Team, with me as lead. Increase visibility when people give trainings. Monthly hangouts.
- Translations. Fixed lots of i18n issues. You can start to translate now for Plone 5. We need help figuring out how to extract messages from Javascript.
- Communication with the community. Collection of activity to get into newsletter. Get teams to report regularly and consistently, also about help they may need. Teams should fill out a document about themselves on plone.org. New information in newsletter. Job openings. Recent launches. Contact Christina. Sponsorship. Social media plan, record upcoming events in a calendar. We like to avoid twisting your arm for information that should be shared with the outside world.
- Mosaic is working in Plone 5. Want to do a release this weekend. Alpha release. Various things that do not work yet, but at least you can try it. It changes various things in the rendering engine, like with tiles. Philip: I was mind blown again and again when seeing it today, lost for words.
- Release team. Commit to doing bugfix releases monthly. Let other people release packages. Write nicer combined changelog for each release, more welcoming, more exciting for new developers.
- Plone RESTapi. Created package to use http verbs in the ZPublisher, delegating to browser views. plone.restapi can build on top of that.
General report-out of this week
- Cleaning up bits of the backend, like portal skins, tools, and also simply pep8.
- RESTapi, preparation for frontend.
A bit scary at the beginning of the week, complaining about what does not work, or all the big work that still needs to be done. But there is a plan for the long term future, with sane steps for short and middle term. So rough roadmap is possible and totally compelling. More energy for people who contribute. We can be brave for the next five years, to see a brighter future.
Big cheer for everybody!
Tomorrow: overflow day. You can have more discussions. Or visit Sorrento or other bits of the surroundings. Paul will start compiling some documents in a kind of roadmap, and people are invited to help. Open space about Plone booth at Bilbao. Plone RESTapi.
Maurizio: the board really helped this year, with declaring this a Strategic Summit, and helping in organizing. Thank you all!
[Image by Fred van Dijk.]
PLOG Friday morning talks
Report-out and talks at Plone Open Garden Sorrento.
On the Trello board there is now a column for teams. Feel free to edit it. And add yourself to a team if you feel lonely and want to join the fun. :-)
Report-outs from yesterday:
- Javascript / RESTful api. First needed is the RESTful api. Afterwards Javascript front-end. Talked about technical challenges for REST, like supporting http verbs in the ZPublisher without defaulting to webdav, Ramon actually has a working prototype for this, too good to be true. Roadmap can be found on https://github.com/plone/plone.restapi/milestones. It will only work for dexterity. How can we make it happen. We can discuss that here and online. Second session was on Javascript front-end. Brainstorming about what each Javascript framework actually does. If you compare things, they should be similar, which they really are not. We do not have to make a future decision now. We currently have patternslib, and mockup on top of that. Patternslib may help you to not have to write Javascript, but you should really learn Javascript anyway if you want to be a web developer. In half a year there will be even more Javascript frameworks, we can decide later. Sorry, there was no pillow fight. We have smart people who can implement a solution. We still have a solid, integrated stack. Outsiders who may want to build on top of Plone will not look deeply into out stack, at how difficult it may be: when is the last time you really dived into the SOLR code? You simply use it, without worrying too much, so we should not worry to much.
- Plone Intranet. Reviewing where we are and how to move forward to ship with a sane architecture. We decided to organize four one-week sprints in the next ten weeks. One online, others in Bristol, Berlin, Arnhem.
- Hackable Plone, Through The Web Plone (TTW). The need for hackability (tinkering with it as power user) was widely supported. Finishing up Mosaic is an important, maybe vital task. Through the web editable .po files, to change jargon. [Look at prototype in collective.storedtranslations, Maurits.] Editable labels per content type, even in the same dexterity behavior; would be really cool, but we have no idea if that is easy or difficult. Repeatable export and import of content and configuration, in the Plone UI please; per add-on exportable config would be great, but might be difficult. Making view, viewlets, theme snippets through the web; make that be seen as a normal supported practice, instead of being frowned upon. Through the web installable add-ons? collective.jbot allows through the web jbot. Some few but loud people are against jbot, but most seem to think it is a fine method for overriding. portal_view_customizations can be tricky, in some cases breaking things simply by customizing it without changes. Being able to do a similar and less breakable thing through the Plone UI would be good. Undo or better versioning of such changes is helpful.
- Branding, positioning. Micro managing has not worked. Various regional and cultural differences that do not work. See Fred's talk of yesterday. We could work towards a common brand view. Get help from community and also from outside. We know someone who uses Plone and does Jungian Archetypes for a living, he was actually here at PLOG last year, so maybe we can ask him to help. plone.com discussions, a bit too much American, enterprise has different connotations. Whatever brand identity we have, does not necessarily influence how individual companies market themselves. Press releases on time can be hard with volunteers, we may explore other ways. Agreement among US companies to hire marketing people. Not a finished discussion. Board and current marketing team will pick this up, and be sure to ask others for their input.
Gil: Berlin Sprint
With Stefania we plan to organize a sprint in Berlin (not the one Guido mentioned above). Working on Mosaic. The coming weeks we will send a formal announcement. Middle of September this year.
Fred: Six Thinking Hats
See presentation at Trello.
This is about Six Thinking Hats, by Edward de Bono. Edward has thought a lot about thinking. Gotta love the meta approach. Creative, lateral, structured thinking, brainstorming, etcetera. Some say it is pseudo science. See for yourself.
Meetings can be discussions, about arguments, ending in 'yes, but...'. A suggestion, followed by risk, idea, emotion, fact, cause, effect, all through each other. Familiar? We have seen it. You cannot compare a fact with an emotion. Six Thinking Hats is about parallel thinking. One thing at the same time. First all think about ideas, without facts or emotions. Do not feed the egos. No showing off.
So what are those hats?
- White: facts, numbers, what do or don't we know, which questions need asking, pretend you are a computer. Examples of data, research. No argumentation, no judgement. Need research, then store it for later. Somebody's facts can be another person's opinion; can you explain, based on your experience why something is 'for a fact' wrong?
- Red: emotion, but feeling. Fire, warmth, intuition. We don't know why we don't agree, but we just don't. You don't have to prove what you are feeling, argument about it. Emotions are there, the red hat just let's them surface.
- Black: risk, disadvantage. Critical thinking. Cautions. Being critical is easy, basic survival instinct to avoid getting eaten by a lion, you will not argue with it. It is important. Sit down with six optimists and pick a new framework... not so good.
- Yellow: optimism, benefits. Look at the bright side. How can we do this. How will the future then look in one year. Proposals, suggestions, constructive thinking. No arguments, but do ground it with facts. Best case scenario.
- Green: creative solutions. Edward de Bono has written twenty other books about this. Get new ideas. Brainstorming, no judgement. Thought experiments. Postpone judgement. Come up with at least five different alternatives, like five Javascript frameworks. Reverse the proposal to come up with a new proposal. Provocation: choose a random word (banana) and associate with the current proposal in mind.
- Blue: control, meta. Blue sky. Overview. Helicopter view. Think about thinking. Meta. Organise the meeting. Which hat order do you start with in this meeting? Role of the chairman probably, or some other dedicated blue person. Observation.
Deal or no deal: if you wear the hat, stick to that thinking direction. Everybody wears the same hat at the same time. Do not say "you are too emotional", but say "you are wearing the red hat". It comes across as less hostile.
How do you use it? You can use it alone or in a group. Start without hats, but then separate the hats when you are stuck: you do not have to use it all the time. Limit the time per hat.
Why use it? It makes things easier. No mix-up of emotions. Think outside your own comfort zone: you may naturally be more black or more yellow. And of course shorter meetings.
The group leader watches the process and decides that people should now put on a specific color.
White hat: what about facts presented as opinions. Use "E-prime": English without the verb "to be". So not "no one is reading news letters", but "in my experience, this does not happen." Start with yourself.
Let's try it! Now!
First try: Let's say Plone wants a new logo. There is a proposal. Discuss it now. Proposal is four squares of blue, yellow, red, green...
Second try: we support Python 3 at the end of 2016.
[Can't summarize these tries, but it was fun and interesting to do.]
Alexander Loechel: Patterns for working Project Teams
It project management, team motivation. Novel from Tom DeMarco: Deadline. In a fictional way he describes software projects and what can go wrong. Other books: Peopleware - Productive Projects and Teams. And Adrenaline Junkies - Template Zombies.
Conclusion on why so many IT projects fail: the major problems of our work are not so much technological as sociological in nature.
He makes lots of points, with patterns and anti-patterns.
My personal conclusion: Plone community intuitively does most of his points right. Keep calm and carry on.
Eric Steele: Hey, when is Plone version X going to be released?
I get this question all the time. It mostly takes so long because I am busy releasing Plone...
Check Jenkins, auto-checkouts, check changelog, etc. By the time I am through the long list of checks for the long list of to-be-released packages, the list has grown by at least ten...
By 2020, Plone will dominate PyPI with over 99 percent of the packages being for Plone, and our cyborgs will take over the world.
Nathan: Security Team
Some of the core people are on it. There is some fatigue on the team, because it is a lot of work when there really is a problem. If your company can help, that would be cool and smart. We need someone who knows Plone really well.
PLOG Thursday RESTapi current status
Timo and friends talk about the current status of the REST api at Plone Open Garden Sorrento. Plus a bit of general javascript talk.
RESTapi current status
Timo started with some proof of concept implementations. See https://github.com/plone/plone.restapi
If it would not work with for example the ZPublisher, then that would be bad, so we should look into that. Let it support http verbs, like POST, GET, PUT, DELETE, instead of assuming it is a webdav request when it is not POST or GET.
Aren't people moving away from that, just using GET parameters? Staying close to REST seems best, Angular and other frameworks can handle it. Workflow actions will use POST anyway.
You will always transform stuff between the saved data and presented data, like saving a uuid and presenting a normal url. You save something and then may get back an object with different values.
Several levels of RESTfulness.
- Resources
- RPC calls
- HTTP verbs
- hypermedia
If we only go for the second level, we could just use the json api. We should play around with the third level, to see if we can make it work.
There is a risk that we break webdav when we fix the ZPublisher. We may have to do that. Webdav works according to some, is buggy for others, or not working at all. For webdav you could look at Accept headers, or discover webdav in some way like that.
Take a look at the dexterity transmogrify code and see if we can take some export code from that. Also https://github.com/collective/plone.jsonapi.core. And look at json schema.
We thought about authentication, but the first phase is just about reading. In a web browser the current authentication will work fine. For non browser visits we need something else, but that can be done later.
The edit schema may differ from the add schema or the view schema. David Glick has written code in javascript for creating a form based on such a schema, using ReactJS and ReactForms.
So we may not need z3c.form then. But z3c.form also does data transformation and validation, you would still need that. If your schema is defined in json, you could use some json schema handling and validation in the backend as well. That is long term.
If you GET a page, you want a json with all the data you might want to see there, so title and fields of this object, list of items if it is a folder, portlets.
Timo: I have limited time to work on this. I do have a project where I am using it. Good if it can work on Plone 4.3 for this. But if it would only work on Plone 5 that would not be a deal breaker.
Hypermedia is there: you can click through the site with json. The json exposes other urls that you could click.
There is a live demo linked on the github page: https://github.com/plone/plone.restapi. You can install a Mozilla json plugin to look at it.
If companies would be willing to give developers money or time for this, that could be helpful. Maybe there is appetite to pool resources. The API design needs to be done before we can ask someone to really dive in and commit. It could feel strange that one person gets paid and others work on it for free, although I wouldn't mind, for me it is a lack of time.
Javascript front-end
Good to get some options out there, get understanding with more people about what we are actually talking about, so if we make a decision it is more informed, and knowingly agreed upon by more people. What are limitations of Angular, React, Patternslib, etcetera? What do we expect from a javascript front-end.
Plone Intranet is using Patternslib and it will be around in 2020.
People will build multiple javascript front-ends for Plone, with whatever framework they like.
Can we come up with a matrix of several frameworks in the next session?
[Well, we tried, but your note taker gave up.]
PLOG Thursday morning talks
Talks at the Plone Open Garden at Sorrento.
Report-out from yesterday afternoon sessions:
- ZCatalog: ripping it out? Setup performance test first, to get baseline understanding of where issues are. Make ZCatalog more pluggable. Enhance visibility of collective.solr in our documentation, good for larger deployments, improve its documentation.
- New plone.org work: halfway finished, most content that we want to keep can be transmogrified, css and responsive tweaks needed, personal profile pages with metrics to show what you are doing as member of the Plone community. PloneSoftwareCenter for the add-ons will be lost. Perfection is the enemy, it would never be finished then. Use collective.roster and collective.workspace. Plone 4. Started a working group to manage this and see it finished: Víctor, Gil, Christina, Fulvio and me, meeting every two weeks. Some of you may be called upon to help. Give us a shout if for example you know about LDAP.
- Marketing/positioning: listed some competitors, talking about sectors, different ways we use Plone. Plone is obviously a very good CMS, but also a platform, a set of tools, that can be used to serve various targeted needs. Unique set of features. Discussion will continue this afternoon. [Fred will present some ideas / pep talk this morning.]
Víctor Fernández de Alba: Activity stream and conversation engine (MAX)
Víctor, Carles, Ramon. We have built a WhatsApp like application on Pyramid. Website. Push notification to app on phone.
First commit in August 2011. Initially designed as key feature for BarcelonaTech university concept of social intranet. But limited resourced for this. We did it bit by bit.
Activity stream with the basic key concepts of activity, comments, likes, favorites, upload images and files.
Conversations: one on one, in group, also with images and files. Doing this realtime using STOMP RabbitMQ plugin.
Push notifications to IOS and Android, including apps for those two.
Aggregate external sources: Twitter.
Authentication is done with oAuth 2.0. Resource Owner Password Credentials workflow using a server we created: osiris. See https://pypi.python.org/pypi/osiris
Activity stream stores activity from users and applications. Application can 'impersonate' a user to feed the stream with useful information, for example when uploading a file somewhere. MongoDB for storing info.
Subscriptions are made against contexts, something with a unique URL. Everything aggregated on the timeline of the user.
Realtime conversations and private messaging, going to RabbitMQ, then to conversation queues, then via an API (WSGI client) to MongoDB. Support for sending images and files too.
Infrastructure. Front-ends: MAXUI.js on IOS and Android. oAuth server. API. MongoDB plus RabbitMQ. Queues and consumers designed for huge loads.
API has 88 RESTful endpoints. Over 600 tests. Powered by Pyramid, optimized for gevent.
Performance: 4000 concurrent users: 100 messages per second.
LDAP integration. Deploying it to Moodle.
What's next: follow people, contextless activity streams. Documentation not only in Catalan.
Resources:
Please give feedback. Maybe you want to use it? If we get enough interest, we can convince our managers to let us go to EuroPython. ;-) We would like to get traction to continue to develop this.
Alexander Pilz: Design First Driven Process
The Plone Intranet Consortium is using this. Let's explain how we look at it, how we define it. Give some insight.
Why is design first necessary?
Part 1: the backend
The developer's fun is the integrator's nightmare.
New UI with Plone as backend: you end up with two separate projects: a backend project (Python) and a frontend project (css and javascript).
The Traveling Integrator Problem. Plone alone works fine. Each add-on you add increases the complexity. The more add-ons I install, the more I need to redo the user interface: one adds an action in a viewlet, another in a portlet, another in a content menu dropdown, so the end user does not know how to use them all.
People do not want to work with an intranet, they have to.
Design is not something on top of add-ons and Plone. It is something that should be integrated in the whole. For that to work, you need to start with the design.
In the Intranet Consortium we started with six companies who were using eight workspace implementations.
Part 2
- Platform approach: an add-on that is as flexible as possible, the least assumptions.
- Product approach.
- Developers approach: first build it, then make it nice.
- Designers approach: make it nice, then develop for it. Emphasis put on the end user.
"Design First" process. Product owner and designer (and only optionally a developer) sit and detail the requirements. You need a designer who can do html and css. A patterns library so that designers can add UI behavior, interaction design, even though nothing yet happens on the backend. You directly use the actual design as the diazo theme.
It is hard to keep developers from designing. They actually like doing that a bit. You have to hit them on the fingers: don't make design decisions yourself, talk with the designer.
Visual versus interaction design. Designers are not just there to make things nice. Theme is the visual design. But there is more: interaction. Usability, user testing. Theming is okay for websites. For intranets there is much less need for branding: you do not need to be reminded for which company you work.
Fred: Branding
Framing effect: what you see, influences what you think later.
I am not a marketeer or communication specialist (anymore), so I shouldn't give this talk. This is just an intro, not a lecture.
You can look at sectors, audiences, regional, etcetera, but it gets complicated. Maybe we have to agree to disagree. Also the wording, top down: marketing, strategy, branding, positioning, campaigning, advertising, communicating, copy writing. Look up a bit. Get out of our comfort zone.
Brands give you emotions and create an identity. They frame you. You see someone and you have an immediate idea: is this person nice or not.
Selling cars. How? They can try to sell horsepower, color, style. Or safety, speed. But deeper down: freedom. Cultural differences. BMW: fun, experience. Audi: technology. Those messages are usually not there explicitly, but it sifts through. Foundation on which they put their other marketing and communication expressions. You don't have to be vocal about your brand identity. Should be consistent, not contradicting. If Paul suddenly shows up in a business suit, I would ask: where is Paul.
This is not about features. Does Paul have portlets? Do I have tiles?
You cannot pick an identity and be done. Time frame of three to five years where you cultivate it. Maybe we already have an identity.
How to describe it. Mission statement, About Us section, mostly describing what you are actually not in the case of corporations. Slogans, persona. Archetypes. No, not the next version of dexterity, but Jungian Archetypes. Twelve in total, like outlaw, sage, magician, lover, hero. An abstraction. Independent of culture: hero evokes the same emotion in America as in Asia.
Example: a sage. Finding truth, wisdom. Weakness: study details forever. Think of Gandalf, Yoda, Dumbledore. BBC: if someone hits a co-worker, you fire him, because it damages your image.
There is more documentation on Jungian Archetypes than you can find on Plone.
This maybe touchy, feely, fuzzy stuff. We are tough, rational developers. So we might need other specialists that actually see this as an exact science.
Back to Plone. Problems have since 2004 been documentation and marketing.
Global positioning or global marketing is not bad, but we are too diverse. If you choose one niche to target, you loose another one.
Try to find a more generic but globally recognizable Brand Identity. Seek help. Derive a brand strategy from this identity. Sharpen the identity that we already have. Focus. Gravitational areas. Schwerpunkte in German. Even distributions can have their own sub branding with aligned personalities. A feeling of what is important in that sector. Look at a competitor, how are they positioning themselves, and can you take the opposite side?
Look at the Plone logo. Close your eyes and be quiet for ten seconds. What do you feel? Probably not much. We have not attached a brand to the logo yet.
A new plone.com and plone.org is nice, but we also need a brand.
Danger of ping-ponging between 'we need to focus on this' and 'no, on that' or 'we do not know how to do this and have no time and money'.
Edward de Bono writes about group dynamics. Imaging six hats with different colors. You can say in a meeting: 'put on your black hat and look at the bad parts' and later 'put on your yellow hat and look at the nice parts', or 'blue hat to look at process'. If six colored hats are in the same discussion at the same time, you will just go back and forth and do not end up anywhere, just go around in circles. This is true for marketing discussions and for technical discussions about our backend or frontend. See http://en.wikipedia.org/wiki/Six_Thinking_Hats
'Plone gives you peace of mind' may sound good to Europeans. Americans may like more 'Plone is stable 24/7.'
Who are you? Mira Lobe / Susi Weigel: I am me. Read it here, nice story: http://www.jungbrunnen.co.at/data/medialibrary/2013/04/Ich_bin_ich_englisch.pdf
JC Brand: Patternslib, Mockup
Patterns make it possible to first create an interaction design, without creating backend code first. Cornelis Kolbach creates designs for sites that still look and work fine without javascript. The patterns are there so it works more nicely or faster when you have javascript enabled, but it is not in the way. It allows a designer to create an interactive design without needing to write your own javascript.
I have replaced mockup stuff with patterns stuff. Mockup is now a collection of Plone-specific patterns, for example for the query string widget used in collections. Patternslib has the non Plone-specific stuff. There is some duplication that we want to resolve. That is the direction in which we are going.
Patternslib is very lightweight. Not a 'kitchen sink' framework. Trying to keep it as vanilla, plain javascript as possible. Lots of third party javascript libraries could be easily integrated. AngularJS maybe not that easily.
Isn't it yet another too Plone specific thing? Patternslib was developed outside of Plone, by Cornelis and Wichert. It has zero dependency on anything in Plone. It is simple conceptually. There is not that much to maintain.
You should usually reuse patterns, instead of creating your own. You may need a new one from time to time, but if you have that often, something is wrong.
Time: not to start a pillow fight, but Angular does much the same thing. But where do you see Mockup in three or four years? In combination with a json api?
JC: We have patterns in Plone now and might as well use them. We need to inform people about how it works, because you sometimes see a pattern where you think: this misses the point. If we use it, we might as well use it in a sane way. Patternslib is not a competition for Angular. We do not want complicated javascript in Plone, which is first and foremost a Python framework. No closely tied javascript client to the Python server.
Alex: Patterns is a simple solution that works at the moment. And it puts us more in the correct javascript mindset. That mindset is more important than the exact technology. Plone as framework should be ready for a pure javascript front-end, whatever it is.
Timo: Three parts that we should do. Cleanup backend, write RESTful api, get some javascript frontend.
Paul: Keep in mind how these things would work for add-on writers. Do they need to learn alien technology or rewrite their add-ons every three years? Also, Mockup documentation should somehow be moved to docs.plone.org.
Timo: Patterns are there in Plone 5. First thing is RESTful api, but that does not change anything yet.
Roel: On the Four Digits Anniversary Sprint we will have an API track, good to have people there who want to work on it.