The following sessions have been accepted to SRCCON. We thank all who submitted proposals. Session descriptions will evolve in the weeks leading up to SRCCON, and the final schedule will reflect these updates and include an evening slate of fun, informal talks and discussions.
SRCCON will run from 9am till 9pm on Thursday, June 25 (including breakfast and non-session evening activities), and from 10am till 6:15pm on Friday, June 26. We will publish the complete SRCCON schedule in June.
Let's build an inclusive dictionary of all the language and terms that create a safe and encouraging environment for a diverse group of people in and out of the newsroom. Some topics include: how to think about gender pronouns, what language to include in a job posting to encourage diverse applicants, how to build inclusive narratives, and what a checklist would look like to ensure representative and relevant perspectives on and in stories.
Facilitated by Josh Kadis
Ignoring anything related to ads is a point of pride for a lot of newsroom developers. But there’s a major shift coming in how ads are sold, served, and measured, and it has huge implications for how news websites will be designed and built. If you work on a site that has ads, you should be getting ready for viewability. Most ads are sold at a price per thousand impressions, and traditionally impressions are counted as soon as the ad is inserted into the page. But the “viewable impression” is counted only after the ad enters the browser’s viewport. For some sites, this means that HALF of all ads served might never be seen by a reader or paid for by an advertiser. This session will provide an overview of online advertising in general, and ad viewability in particular. I'll cover the technologies used to measure viewability and how it might impact the design and development of news sites. Finally, I’ll provide some ideas for how newsroom developers can adapt to viewability, use it to their advantage, and even borrow some concepts to improve the news apps you develop.
Attending conferences with a like-minded community is inspiring, motivating and affirming. We go home full of ideas and energy and hope. Then our day-to-day life creeps back in and it gets hard to move those new ideas forward, becomes tricky to make space for learning the new skills we want, and we can feel isolated from the community we build here. If you can’t attend a conference at all, you can feel all of the above times two. After the conferences, how do we keep that inspiration and how do we stay accountable? For those who don’t have access to conferences or events, how can we make our community — and the inspiration we share — accessible all of the time? What are the obstacles that prevent us from making things happen? How might we build each other and our community up in the day to day, the quiet interludes between the big tent revivals? During this session we’ll work together to identify major obstacles that prevent follow through, and small groups will brainstorm ways to address those obstacles. We’ll leave with a clear sense of how we can collaborate with, contribute to and build our community outside of a conference bubble.
Small development teams, particularly in startups with lean budgets, cannot afford to waste time and resources on failed experiments. How can you make every experiment a success? Frame every experiment as an answer to a question. At Pop Up Archive we make simple tools to manage sound. We had several questions related to the future business model of our company and what kind of audio product(s) we should be investing our time in creating. Hypothesis-driven development helped us identify what we wanted to know, and then helped us define and measure our experiments as a way of answering our own questions. Come spend some time talking and listening about experimentation, data-driven decision-making and innovation. We'll talk tools, process and strategy using Audiosear.ch (our experiment) as a case study.
Many good ideas come out of journalists who are enthusiastic about their beats and the opportunity to capture large audiences. But there are lots of them, and only one or two of us. So how do you say no to good ideas, while keeping those good ideas flowing? How do you tell senior editors that you don’t have the resources when they want Snowfall? How do you determine which of the good ideas has the most value journalistically, and/or most potential for audience, social sharing or revenue? Doing this poorly leads to missed opportunities, time wasted on projects with no legs or shelf life, journalistic flaws, poor execution because of overbooking your time or unrealistic expectations — and burnout from long hours, nights and weekends. Doing it well strengthens our journalism, builds audience and reputation, opens new revenue opportunities and leads to even more good ideas. Successes build on themselves; failures devalue our potential.
If your news organization was a Disney movie what would it be? What happens when you mix equal parts dreamer, realist and critic into a news organization? We know Walt Disney as the man who brought us Mickey Mouse and the Magic Kingdom, but before that he was a high school drop-out who bankrupted his own business. His three room approach to brainstorming took the most fantastical ideas, and developed them into something timeless. How can we bring that approach to the newsroom? How can we encourage our teams to think like Disney dreamers who bring big ideas to life?
Many media organizations have had giant, monolithic software and IT projects that stretched on for years. Some were somewhat successful; many were written off. Some are still ongoing. Some organizations have used these failures to their advantage, leveraging them to create new teams within the newsroom, avoid existing IT structures, merge print and web operations, and the like. These projects and the challenges they face are not unique to media organizations. It turns out, the federal government is loaded with hobbled projects. In government, the failure that acted as the catalyst was healthcare.gov. After, the White House launched a new U.S. Digital Service and recruited some of the country's top digital minds to serve, to help transform government services. It turns out, many of the problems we've all seen affecting large media organizations also affect large government agencies. As government has seen the same failures play out in dozens of projects, it means we're gaining a lot of experience in building effective digital services for citizens and federal employees. (Media organizations also need to build effective services for two constituencies -- its staff and its readers. ) For existing projects, we're getting really good at working through a series of plays to rescue them, and set teams and projects back on track. This session will present what's been learned from the first year of the U.S. Digital Service, and how these lessons can be applied to building effective digital tools for writers and readers alike. We can discuss struggling projects at media organizations (you know, hypothetical struggling projects) and dream up how they might be rescued.
How can we open source the processes it takes to put together events—big and small, from conferences to hackathons and meetups—that serve and challenge our communities? What parts can we play as attendees in making conferences and other events more useful, inclusive, and awesome? We'll talk about planning and program design, outreach and accessibility, pitching talks and being a great participant, and lots more. Bring your questions, solutions, problems, and hopes.
How do we find and scale leadership networks for journalism and technology, particularly in the global context? As news organizations expand their footprints and their partnerships overseas, and as increasing numbers of newsroom workers (not just correspondents!) seek international opportunities, the communities we tap into will make or break our success. This discussion draws on the experiences of Hacks/Hackers chapter organizers around the world to highlight some of the challenges and best strategies for creating and accessing collaborative news-tech communities across different social, political and economic environments. In this guided discussion, we'll talk about how to scale leadership across informal and grassroots groups, how to find and engage effective partners, and the right metrics for measuring the effectiveness of events and the participation of members. By brainstorming challenges faced by specific chapters, we'll gain insight into how the environment for journalism and technology changes drastically in different countries. We'll also create better frameworks for approaching challenges like transfers of leadership, differences in cultural expectations and ways to define value for members.
Facilitated by Jordan Wirfs-Brock
As we design data stories, most of us naturally lean toward visualization and graphic representation. But it doesn’t have to be this way: Take Radiolab’s use of a chorus to demonstrate the color vision of mantis shrimp, or the New York Time’s use of tonal blips to show the difference in finishing time between Olympic medalists. (Find these examples and more at http://listentodata.tumblr.com/.) Audio is a rich, intimate medium that can convey some ideas - like the passage of time - better than graphics and allows you to layer information in sophisticated ways. In this hands on session, I challenge you to think outside the data visualization box and tell a data story using sound as the primary medium. In small groups, we’ll prototype data audioizations using real datasets. We’ll also brainstorm what tools, technologies, software and best practices newsrooms can use to incorporate data audioization into their work.
Want to get your work-in-progress product in front of prospective users but don’t know where to start? Unsure how to get your team comfortable with sharing work before it’s ready to ship? Talking to users can help generate product purposes, validate hunches, and challenge assumptions. User experience researchers from The New York Times will discuss how to foster a culture of soliciting internal and external user feedback. Whether you’re looking to get a few newsroom producers to chime in or want to test with hundreds of people you’ve never met, this conversation about research methods and promoted practices will help you get underway.
Today comments are the most common form of community on news sites, but is that all there is? Comment sections are usually just an afterthought and perceived only as an obligation - in this session we'll explore the unrealized value of comments and other forms user-generated content can take. We'll talk about our learnings thus far from the Coral Project, including the challenges news orgs currently face in creating successful digital communities and some existing solutions from journalism and ~beyond~. Together we'll come up with our ideal online communities and think about concrete ways in which we can integrate these ideas into newsrooms' approaches to content co-creation. If you were building a news community from scratch, where would you start? What are the ways your audience would contribute or express themselves? How would you encourage inclusive and vibrant conversations? What limits would you set, if any?
Any large investigative project or feature is going to generate a wealth of reporting that most users never see. We all have interviews, notes, research and data that inform the stories we tell but get thrown away after a story is finished. This session will focus on open notebook reporting and structured journalism, looking at ways we can better use and share more of what we collect in our reporting, without killing ourselves trying to get it online. We'll talk about tools, practices and culture.
We are not artists and drawing is scary. But visualizing and creating illustrations is one of the best ways to distill and focus a thought or story. In the end, an ugly drawing that makes a point is a hundred times better than a crappy stock photo. And who knows, maybe one of your illustrations will get published some day. How great would that be? In this session we can get out of our comfort zones and doodle our way through a story.
Collaborating with team members based out of another office, bureau, city or even country is really hard. At its very worst, you can feel slow, frustrated, and disconnected. At its best, you will feel flexible, motivated, and energized. This session will discuss the different tools and techniques organizations can use to help teams be effective while working from different cities, time zones, even continents. Topics to discuss: When should you opt for asynchronous, realtime, or in-person communication? How should we log work so that progress is not lost or hidden in email? What tools (Slack, gchat, Basecamp, Facebook groups) work for different types of teams? How do you handle breaking news situations across time zones? How do you foster brainstorming, creativity and team building remotely? How do you train and onboard new team members remotely? How do you keep remote folks motivated and a part of the team?
Facilitated by Matt Waite
Sometimes, the thing a beginner needs to grasp a concept is a simple analog. For instance, I taught a class in data visualization and one of the early classes was using LEGO to visualize data. There are all sorts of code concepts and data concepts that students -- from university courses to workshops -- struggle to grasp. What if we came up with a list of goofy, hands on ways to teach concepts that others could steal. How could you teach loops by making people run around a room? Or filtering? Or basic algorithms? Or visualization concepts? By making new concepts memorable for beginners, we stand a much better chance of spreading knowledge. Come throw out your ideas.
Bring a computer with a web browser and/or command-line terminal to this session and learn how to use the Dat data version control tool in combination with the Flatsheet data editor application to version control, push, pull, diff and merge datasets. Here's what we will cover in the workshop: - Sending a data "pull request" - Merge data contributions from others - Set up data import pipelines to wrap legacy data sources/formats - Update local copies of data with new changes - Revert back to old versions of data - Compare two versions of a dataset We will have some example datasets to use, but also feel free to bring your own raw data to try out as well. Part of the workshop will be on the command-line, and part will be in the Flatsheet web application. You will need to install both the Dat command line-tool and the Flatsheet application on your own computer, and you will be able to do this at the start of the workshop (it only takes a couple of minutes). Some basic command-line experience (Mac, Linux or Windows) is necessary to get the most out of this workshop. More about Dat and Flatsheet: Dat (http://dat-data.com/) is an open source version control and data sharing tool for data sets. It comes with a command line tool called 'dat' that lets you do things like 'dat pull', 'dat diff', 'dat merge' and 'dat push'. The goal of dat is to let you automate your data workflows so you can share and consume changes to datasets with others easily. Dat is funded by the Alfred P Sloan Foundation and has a primary goal of being used by scientists to publish data for reproducible research and collaboration. It is currently in 'beta'. Flatsheet lets you edit data sets in realtime with your team. If you've used Google Spreadsheets with a library like Tabletop.js to create an ad-hoc mini-CMS, Flatsheet solves that problem more effectively, and is an open-source tool you can host on your own server. Flatsheet integrates with Dat, so you can use Dat to clone any sheet, edit locally, and push changes back to Flatsheet. Flatsheet recently received a grant from the Knight Prototype Fund, as well as a code sprint grant from OpenNews. You can see a work-in-progress example at http://data.seattle.io
It's been 10 years since chicagocrime.org won a Batten award for innovation in journalism. In that decade hackers have joined the ranks of newsrooms large and small, and then left newsrooms to join startups and non-profits (If they Left newsrooms is that good or bad?). We now have many tribes of news nerds, journo-hackers, data wranglers and user experience researchers. Let's take a step back and see how large our community has grown. Who are we? What jobs do we have? How are our teams built? What problems are we trying to solve? What are the ingredients of a successful team? We plan to do a survey leading up to SRCCON to take stock of anyone who identifies with the DATA-journo-tech-design community. We'll present the results at SRCCON and then lead a discussion about what we found: Are we missing some key members of our community? Are we tackling the right problems? Are we learning the right skills and reaching out to the right people? How do we help news organizations create and sustain great teams? We don't know, but it's been a decade since our little community got started. Let's find out who we are.
What's MySQL hiding? Is PostgreSQL ready to lead your news app? Just how is SQLServer using your precious resources? Just because your SQL is similar across platforms doesn't mean they work the same under the hood. We'll look deep inside and see how different database platforms work at a granular level, and we'll also show hilarious negative ads about databases.
Facilitated by Noah Veltman
No matter how useful a piece of open source software is, documentation is often the difference between whether it flourishes or dies a quiet death. But writing the docs is still an afterthought for a lot of developers, something to check off a list at the last minute before moving on. The end result is a lot of wasted potential, great tools that put off potential users because nobody can figure out how they work. In this session, we'll discuss patterns of effective documentation and our own experiences as both readers and writers. How do we balance readability and precision? How do we write docs that serve both beginners and experts? How do we choose good examples? How do we make writing the docs a first-class citizen of any project, something that feels integral and not like extra homework? When we're reading docs, what makes things click and what makes us give up? Finally, we'll split up into groups and break out the red pens for close readings of documentation from a selection of popular libraries, and maybe even make some pull requests with our edits.
As journalists, we know how useful LexisNexis can be. Companies do, too. And they are spending millions to build or buy sophisticated CRM systems that track and link their customers through not just social media and online buying preferences but also through public records. But we also know how flawed the data collected by these CRM systems and LexisNexis can be. Public records are not necessarily clean data. Nor do they often tell full stories on their own. Having access to good data within the right context is immensely valuable. That’s in part why we’ve seen data stores such as ProPublica’s and the Texas Tribune’s show such promise. As we consider revenue streams to support good journalism, data may be one of those that gives us the resources and the independence we need. Let’s talk about how to best monetize data responsibly, ethically and without sacrificing journalistic standards. Proposed topics for discussion include: * What datasets should newsrooms be collecting as a matter of course — what is valuable? How should we define “valuable”? * How should these datasets be published? How much fact-checking is the right amount of fact-checking, particularly with significantly large datasets? What standards (if there should be standards) need to be put in place re: ideas such as version control, auditing back to the source and linking people within datasets? * Should all data be published? What are our responsibilities in terms of protecting privacy? How might our decisions on what to publish affect open records laws — could we see a backlash and how much should concern over that factor into our decision-making on what to publish? (For example, whether or not home addresses can be released by government agencies has been a huge topic in Pennsylvania. The Commonwealth Court recently ruled that agencies can’t release home addresses under the Right-to-Know Law without informing each person that his/her address would be released and giving them a chance to contest it. But this ruling doesn’t seem to apply to the release of home addresses in the voter registration database. Yet. If we use the voter registration database to map voters, how granular do we want to be in what we publish? How might that decision affect the state’s ongoing debate about the openness of those records?) * Let’s also talk about how, technically, these data “libraries” could be built — how can this idea of monetizing data work practically and efficiently, especially for small to mid-sized newsrooms?
Interested in using maps to identify food deserts, compare neighborhood distances to voting polls, or calculate the population within a flood zone? Are you guilty of creating overlapping geographic layers to show correlations? While many newsrooms use maps to visualize geographic information — everything from election results to wildfires — a few simple techniques can make those maps more informed and insightful. We’ll show you how to interview geographic data using network analysis and discuss a few common concepts (buffers, spatial joins, distances, etc). We’ll talk about how specific stories have analyzed geodata using a combination of free tools such as QGIS, turf.js, and leaflet.js. Afterward, we’ll open the floor for you to share your own experiences and questions. If you have your own favorite techniques or tools, give them a shout out! This session is for beginner and intermediate data journalists who have used maps in their reporting, or for anyone who wants to go beyond simple geographic visualizations.
Design's user-centric orientation places the needs and expectations of users at the center of the designer's decision-making process. Journalism’s objectivity ethos has journalists striving to report on facts (and not their personal attitude toward facts), with fairness and accuracy. With newsrooms embracing new skill sets and welcoming more collaboration between people with a variety of professional backgrounds, different practices and traditions collide. Where is the line between designing for an audience and pandering to that audience? In this session we explore user-centered design’s fit in the newsroom and the processes of reporting, and how characterizing the audience for a story shapes decisions about what, how when and where a story is told.
Facilitated by Linda Sandvik
Like the outdoors? Aerial photography? Documenting illegal deforestation in central America or mapping relief efforts after a natural disaster? Maybe kite mapping is for you. Sure, all the cool kids are using drones. But when journalists get arrested for trespassing when they are using their shiny + easy to spot drone to film correctional facilities, their colleague flying a kite is less likely to be stopped (what, I'm just flying my kite?). Let's make a kite and go for a walk around a Minneapolis lake or two. (Note: this requires some wind. But fear not, if there is no wind the backup plan is to do (helium) ballon mapping instead. Still cheaper than a drone). After kite-flying we'll have a look at the photos, stitch them together, contribute it Open Street Map and talk about some cool kite mapping projects. (this workshop will work over two days, day 1 mapping (a couple of hours), day 2 do some stuff with computers)
Facilitated by Katie Townsend
In this community dialogue session, attendees will have the opportunity to learn about existing legal resources that are available to independent journalists and nonprofit or startup new organizations free of charge, to ask questions of First Amendment and media law attorneys, and to communicate their biggest needs when it comes to legal support.
The workflow system of getting text (i.e. stories), photos and static graphics into the printed editions of newspapers has evolved over literally 100+ years and it is now a very, very refined process in every newsroom we’ve been in. Putting those same items on digital has essentially just been tagged onto the end of that process. But in many newsrooms this workflow doesn't work well for digital-only work, particularly when it involves data. We’d like this session to be a work-group format with a goal to create the ideal workflow -- from idea germination to publication. This should include best practices for communication flows, deadlines, how/when items will be edited (for usability, clarity, style, grammar, spelling, etc), process for creating/sharing/discussing mockups, first drafts, etc. A very key piece should be who should be included in the process and when (and by “who” we want to identify skillsets, rather than specific job titles). Some of the questions that could be used as part of this discussion include: How and when should people (i.e. reporter, data wranglers, devs, editors, copy editors) get looped in? What are realistic time frames for getting a digital-only project completed (obviously dependant on the scope)? How should deadlines be used in this workflow? What skillsets are needed (this goes back to the “who” is involved piece) to ensure you’re producing high-quality digital product? We’d like to split into three groups, each working on their own proposed workflows to address three different scenarios: 1) a digital product that accompanies an enterprise story that is weeks or months in the making, 2) a digital product that needs to be done quickly (either daily or short-term), either with or without a story and 3) a stand-alone digital-only product, such as a news app or tool which does not heavily feature a text component. We realize many people attending the session come from organizations where there are a lot of road bumps that might need to be fixed before such a system could be put into place, but we don’t want to spend this session just talking about the problems. At the end of the session, we’ll combine the three groups to discuss the implementation piece. Who has had success? What worked, what didn't? How do you convince higher-ups that this should be a priority? How do you cut through the office politics? We want to come up with an ideal workflow that can be used by newsrooms as a goal to achieve, since each newsroom will likely have its own unique problems to resolve before achieving it.
We gave a couple of people in the Quartz newsroom training in Adobe Illustrator and our graphics style guide and set them loose to make their own graphics. At The Wall Street Journal, reporters regularly make their own quick charts with tools like Datawrapper and Excel macros. Let's talk about how terrifying that is and what there is to keep them making great work.
Newsrooms developers often build applications and visualizations using dynamic tools like d3.js, AJAX, canvas and others. However, these approaches to data viz and digital storytelling often don't consider users who have low-bandwidth Internet connections, budget smartphones, screen readers or hi-res displays. This session will look at existing data visualization projects and see how they could be adapted to work on low-end phones, computers with accessibility enhancements and other environments. We'll also brainstorm techniques and approaches for building wonderful and beautiful digital stories that *everyone* can enjoy.
Facilitated by Steven Rich
Machine learning is suddenly the new, hip thing in data journalism. But like every tool in a toolbox, it has some uses but is not a go-to tool in every situation. This session will look at how some journalists have used machine learning and in what situations it's best and in what situations it should be avoided.
Last November, The New York Times challenged news sites to fully support HTTPS in 2015. What does it mean to meet that challenge? This session will discuss the problems we encountered moving to HTTPS (and how we solved them). We'll then give you hands-on help with anything you need: server configuration, certificates, mixed-content warnings, CDNs — even ads, analytics and A/B tests.
Version control systems are indispensible for engineering teams, but often afterthoughts in the tools used by writers and editors. The patterns for version control we employ today, invented for specific software development cases that don’t always fit our needs, often force us to shape our tools and practices in ways we might not realize. Let’s change that. If we were to start from scratch, how might we design the kinds of version control systems that empower writers and news developers? How can we explain and facilitate powerful and complex version paradigms like branching and merging in the context of a reported article? How might we expose that process to our readers? Let’s explore some of the implementations of existing version control structures—resilient storage, atomicity, concurrency—and try to conceive of new ways to look at, modify, and understand our content and news applications.
What do voice-recognition assistants, Slack bots and the latest crop of mobile payment apps have in common? They all use natural language messaging as the interface — an area journalists have largely ignored over the past decade. It’s time for a closer look. In this session, we’ll explore the rich, hidden history of using messaging as the medium for fun, quirky, and occasionally powerful applications, ranging from SmarterChild and Siri to SnapCash and Wolfram Alpha. What can newsrooms learn about interacting with their audience in this intimate format? Can we design a more personal way to tell stories through messaging or develop new messaging products to serve our audience?
How newsrooms conceive of and measure the impact of their work is a messy, idiosyncratic, and often rigorous process. Based at times on what simply seems worth remembering during the life of a story or, at others, on strict guidelines of what passes the "impact bar." Over the past two years, we conceived of and constructed NewsLynx (http://newslynx.org) to address two needs: first, as an attempt to understand how and through what processes news organizations large and small are currently approaching the "impact problem" and second, if we could develop a better way — through building an open-source platform— to help those newsrooms capture the qualitative and quantitive impact of their work. Coming two weeks after the official public release of NewsLynx, this session will serve as the first opportunity for journalists, editors, and open-source hackers to work with the project's creators to install, configure, and extend the platform in their newsroom. We'll discuss the successes and failures we encountered throughout our beta test with six non-profit newsrooms and brainstorm potential means of extending the platform moving forward. If all goes well, we'll help technically-inclinded audience members actually deploy an instance of NewsLynx.
Programming creates so many technical and creative inventions that it's natural for aspiring programmers to dream of big projects in the cloud. But this ambition ignores the actual goal of programming, which is almost completely about making machines do mundane work. And it is counterproductive to learning how to program, which requires consistent practice as in every other form of literacy and art. So this session will be about mundane programming. Programming not to be the next Zuckerberg, or to get a better job 3 months from now, but to make today or just the next ten minutes more enjoyable. Instead of focusing specifically on how to code, we'll expand upon the reasons of why we code (though seeing is often believing when it comes to code, so feel free to bring both ideas and Gists). And we'll trim the personal prerequisites of programming, which don't include being an entrepreneur, having a profitable idea, building a website, contributing to open source, or changing the world or your career. Programming can be learned, and done, with a willingness to learn and a wide variety of small problems to practice upon.
Sometimes the reasons we created our newsroom chat bots — delivering horoscopes, telling horrible knock-knock jokes — aren’t the kinds of reasons that organization leaders will readily appreciate. In this session, we’ll talk about the tricks we’ve taught our bots (or would like to teach our bots) that help our team (whether we’re developers, reporters, or otherwise) get our actual work done — even if the bots’ work is never seen by readers.
At NICAR15, during the NICAR-commons hallway chat on salary, we started having a great conversation about the role of gender in salary, negotiations, which eventually led to conversations about women on tech teams, inclusive culture on teams, even the ideas of using your married name vs maiden name at work. Let's bring this to SRCCON and keep surfacing these topics.
We all have to work together in the end, but the hiring process can get that relationship off to an awkward start. Employers may feel unable to find the best applicants, while applicants often find themselves frustrated by a completely opaque process. Throw in unconscious bias, an emphasis on the elusive "fit," and negotiations about pay and it's no wonder both employers and applicants come into this process with a lot of anxiety. In this session, we'll share our experiences about the roles we've all played in this process: whether it be helping craft job postings, recruitment, hiring, or applying for jobs. We'll discuss strategies for improving hiring and craft some suggestions to bring to a discussion at ONA.
Working in news can be punishing, and over time, it can cause real emotional and physical damage. How do we get to a point where work-life balance -- however we define it for ourselves -- is an attainable thing, and not merely something that elicits a weary ¯\_(ツ)_/¯? Let's talk about why life in news can be so hard, how we can address the larger issues (and what's out of our control), and what we can do to take care of ourselves and each other.
Facilitated by Ryan Murphy
Accessibility is often on our minds as we build products for the web, but are addressing these challenges in the best way? Many of our approaches tend to focus on the disability or impairment we are trying to accommodate. What if we approached these challenges from the perspective of the hardware and software being used instead? When's the last time you tried navigating your site with just a keyboard? At 200% zoom? A Wiimote? As Anne Gibson puts it in her great A List Apart piece "Reframing Accessibility on the Web," accessibility should not be just about determining "your audience and building to their needs" – accessibility should be a "trait of the website itself." We'll chat about how we approach accessibility, touch on common misconceptions and mistakes and look into techniques to encourage mindfulness as we plan our projects.
Facilitated by Sisi Wei
Learn what it really means to play Dungeons & Dragons — and how the creative concepts behind roleplaying games are especially applicable to teaching journalism. After playing some (adapted version of) D&D, we'll discuss examples of how others have used roleplaying to teach, which lessons lend themselves to roleplaying, and finally, create as a group a lesson plan for making your next class an adventure. The unamended title of this session pitch is: The Dungeon Master's Guide to Teaching Journalism, 3rd Edition, Revised (v3.5)
Facilitated by Daniel McLaughlin
Let's talk about archives! An organization that's been making news for a while has a lot of cool stuff in the attic. How can we add context and enticing entry points to turn that raw material into a resource for our readers? What approaches has your organization tried? What off-the-wall ideas would you like to try? These questions are also relevant to the journalism we're producing now. Whether you're stretching the limits of the CMS or telling stories on platforms unlikely to exist a decade from now, how might you keep the archives of the future in mind? How do you balance the goals of preserving the content and preserving the material experience? How many Snapchat stories fit on a roll of microfilm? Let's find out, together.
Facilitated by Derek Lieu
A lot of tools are built off the Github API. Some are great. Some are funny. One of them is a bot that accepts pull requests to it's own code, based on the number of upvotes the pull request gets in the first half hour. Sort of like a semi-sentient, crowd-pleasing roomba. I'd like to share some of the things I've worked on that use the Github API (prose.io), and I'd love to hear what others have to add. Together, we can learn a little more about the site that many of us use everyday, and maybe come up with a better, more sentient roomba.
How can we build good products if our energy is spent tearing each other down? We all know that we value a “good team culture,” but we’re often vague about what that means or how to achieve it. But what if it’s as easy as setting out your team practices as a checklist, the same way you would for any other project? For instance, making sure that individual interactions between team members — even arguments — are approached in an “actively positive” manner? Or ensuring that every team member agrees and understands the grounds on which a proposed feature is judged? Thinking about “culture,” precisely and vigorously, comes in especially handy when your team needs to onboard junior members, or when there’s a on-the job learning happening (which is, let’s admit it, all the freaking time). Using techniques and advice from an industry that is all about making communication and relationships healthier, we’ll work together in this interactive workshop to create better frameworks for how we give and receive feedback. Participants will leave with actionable strategies for how to make space for criticism on their teams, how to wrangle all the egos, and simple ways we can encourage and support each other as we build things every day.
Facilitated by Ivar Vong
Whether you’re deploying a static app or a news app with a half-dozen databases, you’re making infrastructure choices about where those HTTPS requests go. How do you weigh the tradeoffs of S3 vs AWS vs something else? Does your app emit the best cache control headers? When should a feature be static, when not? How many databases should you be allowed to put in production? How do you monitor all of this stuff (both performance and errors)? When should you integrate with another service, when should you build it yourself? And now that you have all these internal services, how do you coordinate them? I built The Marshall Project’s website. Many of us build apps like this, whether it’s a news app, CMS, or plugin for an existing system. Let’s enumerate the choices we tackle when we build an app and explore their tradeoffs by sharing some war stories. At the end of the session, we’ll come away with a framework for asking the right questions when building your next app.
Mobile is growing exponentially and mantras like "mobile first" and "no native app" are making us all look silly. Mobile is eating everything and if we don't give this Pacman of eyeballs the respect it deserves we are all doomed. What works for you might fail for someone else. We'll talk about how you find what's right for you from technology to content and really huge to just right. I'll present a lot of unknown mobile metrics and show how they apply and don't apply to media. We'll talk about building mobile teams and when to stop saying "mobile" and just accept it's everything.