Portfolio manifesto // design parameters

1. It's for presenting one individual. Professional and private.

   Representing professionals that have a small support team (e.g., a lawyer office) is in the scope, too. Managing a Portfolio site with 1-N site administrators (but still to present one individual) is supported, too. But representing a larger group is out of scope. Portfolio won't disallow to "abuse" itself for groups and will try to implement all functionality in a way that allows for that, but none of the out of the box configuration will cater for that case otherwise.

2. It's not a blog. It's not a corporate site. It's not a community.

   But it shares a few aspects with each. Portfolio site owners want to present themselves professionally. They are specialists. They want to occasionally publish "updates" on topics that matter for them and their followers. They want to get feedback and enable interaction. They want to leverage external social networks/communities and web apps/services that they're already using.

3. Constantly rethink what a portfolio site means today and in the future.

   Focus on modern, state of the art technologies in 2012. 2011 is too old. Serve the basic functionality for a portfolio site. But execute current international best practices (e.g., on privacy) and encourage web standards (such as RDFa or OAuth). Always exceed expectations. Lead as an example for how to represent someone on the net today.

4. Serve the audience. Solve actual user problems.

   Stick to the defined scope and use-cases. Make it work, intuitively, for the target audience. Respect the technical skills of the actual site owners/users. Try to make it work for shared hosts, but don't make that a requirement.

5. It's still Drupal. No lock-ins. No special cases. No limitations.

   Portfolio actively leverages projects outside of Drupal core. But no custom code. Only existing contrib projects and libraries. Portfolio's code consists of configuration only. It is bound and constrained to the usability and features of involved projects. Joint use of them aims to channel contributions, be it for maintenance, upgrades, or improvements.

6. Push the web to its next level.

   The very distant long term vision: Centralize web communication on your own portfolio site, pushing data to other networks/sites, but retaining authority and power over own data and content. Leverage external sites/networks as they come and go, and allow to replace them. Turn each portfolio site into a web app/service on its own, serving as identity provider, and potentially communicating with other portfolio sites (based on web standards and protocols like OAuth) to enable data sharing and interactions without any third-party in between.

7. Transparently document all product design processes to enable the Drupal community to build other products.

   Allow the Drupal community to learn and figure out how to build an actual, successful Drupal product that is designed, developed, and maintained completely in the open and in the community. Stop the scratch-your-own-itch mantra of current installation profiles. Enforce transparency and document all processes and decisions. Favor community involvement over do-ocracy. Allow others to copy and project the entire process for different products, and to learn from our mistakes.

8. Maintenance

   Update/upgrade/migration path... to be figured out later. Let there be experience first.

Use-case

1. Portfolio aims to present a professional or personal individual.
2. Being the first product designed by the community, it can be less strict about its scope and use-case.
3. Different perspectives on the application are possible, as long as the primary purpose stays the same.
4. Portfolio's design parameters aim for a single-purpose solution and set a clear direction to avoid product design and management problems, but multi-purpose scenarios of the product are still taken into account.
5. Its use-case is based on user research; an inventory of related but differing use-cases was analyzed and it aims to solve the common challenges that are worth providing solutions for. The risk of being too generic was mitigated by developing a primary persona for the product to have a clear focus point.
6. Portfolio's product design and development is driven by real world use-cases. Many of them being represented by actual Drupal community members and project participants.

Related

• Snowman FAQ