Students will collaboratively assemble, connect, and present a collection using Are.na as a platform/
The web is a big place. Think about how one sifts through it all. How do we save things from this vast repository? How do we organize things within its systems? How do we connect them together? How do we prioritize (or deprioritize) what we have found? How does one create meaning within this all?
The web is also inherently a community—of people, of sites. This community is built, in large part, upon tools that facilitate interaction, collaboration, and connection. These systems (and thus the community) have structures of their own—which one can work with, or against. Think of the ways you can use these tools for their strengths, within their limitations.
Students will together collect items on a theme. They will then give the collection shape and structure in the form of a website. The site should contain all the contents of the collection, as well as an explanation of the organizing principle. The design of the website should reflect the intersection of these items—an interface—and allow for interaction within it.
The goal of this project is to apply all the skills you’ve learned thus far in a media-based project—connecting varied content, tools, and form together. We will introduce and use JavaScript to facilitate this, understanding how it meshes with HTML and CSS to dynamically render and manipulate pages. The website should be responsive, and should allow for and facilitate interaction with the collection.
Assemble a collection
Assemble a collection around a theme of your choosing. This topic should start from your own interest, but be aimed at broader use and collaboration from others.
Gather and link your items in an Are.na channel, taking care (as in editing) the metadata applied for each. In the channel description, explain the idea behind your items and why they constitute a collection. As you curate this grouping, consider what brings them together—what are their links to each other?
You should have at least 30 items, to start. They should include all the Are.na content types (don’t worry about ePUBs) for a varied mix of audio, images, links, documents, text, video. Everything in your grouping should be collected—that is, things you did not create yourself—and there should be a clearly identifiable, cohesive theme. We’d also like some content to come from the web, not just linking of existing blocks.
When you are done, submit a link to your channel:
Due January 31.
Swap collections
Students will hand off their collections to a classmate, who will then use it to complete the rest of the project. The creator will be available for questions and consultation about the original collection—but going forward, everyone will be working with an adopted collection, and the final result is in their own hands.
You will each then be a steward for someone else’s idea. Working with other people’s content is inherent to our discipline—very rarely do you have complete control. Think about how you can reflect the original intent of the collection, while also imbuing your own taste and interpretation within the theme.
We’ve randomly assigned these connections:
| Hao | → | Kirsten |
| Kirsten | → | Kritika |
| Kritika | → | Rebecca |
| Rebecca | → | Wenny |
| Wenny | → | Rodrigo |
| Rodrigo | → | Sabrina |
| Sabrina | → | Xinyi |
| Xinyi | → | Zil |
| Zil | → | Alexis |
| Alexis | → | Angelica |
| Angelica | → | Cristina |
| Cristina | → | Hannah |
| Hannah | → | Hao |
| JC | → | Shaurya |
| Shaurya | → | Sarah |
| Sarah | → | Lucy |
| Lucy | → | Emily |
| Emily | → | Shaoran |
| Shaoran | → | Sachi |
| Sachi | → | Hana |
| Hana | → | Bhroovi |
| Bhroovi | → | Vicky |
| Vicky | → | Dhruvil |
| Dhruvil | → | Vera |
| Vera | → | JC |
Students should get in touch with each other after class. The creator of the collection (left) should invite their classmate (right) as a collaborator on Are.na, making sure the channel is set to Closed. The creator can help explain the theme (beyond what is in the description) and can answer any questions around it for its new keeper.
You will not be able to edit (or delete) the description, blocks, or metadata of the original collection yourself—this is the hand you are dealt. You might be able to talk to the creator and convince them to do it for you, but they are not required to—but nor are you required to heed their feedback. Part of being a designer is also watching other folks execute your ideas, for better or for worse.
You can however add new blocks to the channel and also adjust their order. Each student should now add at least 10 of their own items to their collection—
When you are done, send us the link to your adopted channel:
Due February 7.
Static content sketching
We’ll move right into design in code, using the collection you’ve been given. To begin, contemplate your blocks. Consider their medium and relationships, and the text and metadata available to you. Think about the word interface in all of its meanings—not just as a visual UI, but the way in which things meet and intersect.
Think about your site, and its design, as this membrane between things. Your design should participate in and relate to the theme. Think about the design of the site, but also about the design of the individual blocks together.
In code, begin with the furniture of your channel—the title, description, an area for your blocks. In this phase, we’d like you to “hard code” at least one example of each media type image, text, link, and PDF with the exact content from the block online. We will connect Are.na next; for now the media/assets will live within your repo and DOM directly—manually copied/
This local, static subset of your items will also help inform your design. This is no different from how we’ve began previous projects—you should first start with semantic DOM before moving into responsive, mobile-first, variable-structured CSS.
Provide a link to your repo and URL, once it’s live:
Due February 7.
Are.na as an API
We’ll now link the Are.na channel to your static site—using its Application Programming Interface (API) to pull in its content directly. This will utilize JavaScript (JS) to dynamically render the page content from the channel. With the foundations done in the static implementation, this connecting-the-dots step will populate the site with its real content.
As you respond to the content, ask yourself: how will you order/organize the collection? How will you incorporate, differentiate, and relate the different content and mediums? How do you embrace an existing theme within your own expression? Can you develop a narrative within the theme?
There should now be no remaining local media or assets in your repo; everything should be coming dynamically from Are.na. You are welcome to continue to add blocks to your channel and refine it in the CMS there. And then we will move our focus to refining the design and layout of the site:
Due February 14.
Adding interactivity
Here you will introduce interactivity and dynamism to your project, via JavaScript.
Think about someone using your site—how can they manipulate the collection? How can they change it? How can they explore it? We’d like you to consider sifting, grouping, filtering, sorting, linking, altering. This isn’t prescriptive; work back from your collection and its theme. JavaScript (and the functionality it brings) is no different from your content and styles—it should be in service to your concept.
You’ll also continue to refine your design and build, based on feedback from us and your peers:
Due February 21.
Refinement and review
In the final week, we’d like to see a focus on refinement and polish—from our feedback and from your evolving design considerations. With the core of your content, design, and functionality in place, here we want to see it taken further.
Last, as with your other projects, you will present your work to the group—discussing its concept, iteration, and implementation.
Make sure that we have your final links:
Due February 28.
Our expectations
We want to see your effective design, typography—and now interaction patterns—that build off of everything we’ve discussed thus far. At this stage, we are also expecting a level of finesse/refinement to your design and executions.
Our usual technical/practical requirements:
- As before, your projects should be submitted as live, public URLs
- These should work, as you intend, on any computer (not just the yours)
- The page should be responsive across breakpoints
- Your presentation should demonstrate all of its behavior, and is part of the project
And some additional considerations:
- You are now allowed to use images, obviously
- Your project must show all the blocks in your channel (all types)—but how is entirely up to you
- We don’t want to see 25 Are.na reskins/templates—these should be unique to your collection and its theme
- We want some considered interactivity, but not just for the sake of it
- These should feel alive—both in content, and in form—within your concept
Notes on format
-
We’ll be in two groups again, following the split above. We’ll post the classrooms and (differently random) order shortly before class next week.
-
Each of you will have about 6–7 minutes to present your work, and we’ll give you a notice at the five-minute mark. You’ll do this from your own machine, signed into the Zoom, from the live URL you have submitted—a.k.a. “The Usual.”
-
Again, this doesn’t have to be in a deck—but it should use the entire time and cover your whole project.
Introduce us to your channel, its concept, and your execution. Even if it isn’t in a deck, give us your thought process and tell us the story. Make sure we see it on mobile and across all the breakpoints. Thoroughly demonstrate the interactivity. Your presentation remains part of the project—remember that if you aren’t into it, it’s hard for anyone else to be!
-
Each presentation will be followed by several minutes of feedback and critique from your classmates and from us. We’ve set up the groups so the original channel creator will be in the room—and they will start off our discussion with their response.
-
And as we did last time we split up, your in-person instructor will evaluate the work and presentation; the other one of us will look at the URL and code, afterwards. We then average our scores for your overall project grade.