CMS Prototype Gallery / Case Study
CMS Module system
What I wanted to solve
A CMS has to support quick everyday updates as well as actions that can remove important content. I wanted those tasks to feel related without treating every decision as equally risky.
The portlet gallery brings page creation, deletion, login, and calendars into one set of examples. I focused on the decisions inside each task: what information is needed, what should happen next, and when the interface should ask someone to pause.
My contribution
Experience design
I designed the flows for creating pages, removing content, signing in, and browsing events, including the decisions and confirmations within each task.
UI design
I designed the forms, dialogs, login screen, and calendar views, giving each tool a clear layout and familiar controls.
Prototype development
I built the underlying portlet prototypes, bringing the page flows, confirmation states, and calendar interactions into the browser.
What I focused on
- A page needs a place to live
- I brought the folder, URL, template, and visibility settings into the page creation flow. Adding a title is only part of the task; editors also need to know where the page will appear.
- Hiding is not deleting
- I separated minimizing a portlet from permanently deleting its content. I wanted that difference to be clear before someone commits to either action.
- Different calendars for different spaces
- I used a mini calendar for quick date selection and a larger view for browsing events. Each needs enough detail for its job without filling the page with unnecessary controls.
How can common CMS tools stay quick to use while giving people enough context to make the right decision?
How the flow works
- 01
Start a task
Choose the page or portlet action that matches the intended change.
- 02
Set the details
Provide the content, location, and display settings the task needs.
- 03
Check the impact
Understand what will appear, move, or be removed.
- 04
Confirm or leave
Commit the change or return without taking the destructive action.
Why I designed it this way
Put related page settings together
I kept the title, location, URL, template, and publishing choices in one form. It is a longer form, but it lets editors check how the settings fit together before creating the page. Clear labels and groups help break it up.
Add PageMake deletion a deliberate choice
I put minimizing first because it keeps the content available for later. Permanent deletion has a separate step that asks the editor to type DELETE. The aim is to give them a clear pause and a way back before removing content.
Delete PortletMatch the calendar to its space
I kept month navigation compact in the mini calendar and gave events more room in the larger view. The layouts serve different needs, but date selection should still feel familiar between them.
Monthly CalendarA closer look at the designs
Add Page
I brought page details, folder placement, template choice, and publishing settings into one flow.
Delete Portlet
I separated hiding a portlet from deleting it, with an extra confirmation for permanent removal.
Login Page
I designed a focused sign-in screen with room for the site's branding.
Mini Calendar
I designed a compact calendar for places where space is limited.
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| 28 | 29 | 30 | 31 | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
Monthly Calendar
I gave the full calendar more room for browsing single-day and multiday events.
| Sunday | Monday | Tuesday | Wednesday | Thursday | Friday | Saturday |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Looking back
I wanted the everyday tasks to stay straightforward and the risky ones to give people a chance to pause. Building these prototypes let me work through the details of each flow, from the first field to the confirmation and the way back out.