Welcome to DCI 110

Here’s a bit of the opening that I’m telling to this year’s DCI 110 class.

Obviously, this course is going to be very different from how I would teach an in-person course. But I’ve been working all summer on preparing this virtual experience for you. I’m very excited about teaching this way, and I hope that you find it a positive experience.

The course will make heavy use of canvas and there will be a lot of videos like this that I’m creating for you. I have another video that goes over the structure of the course. But first I want to outline what this course is about.

It’s web programming for nonprogrammers. Let me say that again, for nonprogrammers. I don’t expect you to have any knowledge of computer science. You may even be intimidated by technology. That’s fine. I was like that as an undergraduate….a very long time ago. I have designed this course to build your confidence in learning how to code.

A lot of this course is about computational thinking, because programming is problem solving. Programming is solving problems with computers. And this course is about web programming. The Internet is something we all use everyday. It’s what making this virtual course even possible.

By the end of this course you will have some idea as to how apps you use everyday actually work. Now, let’s be honest, with one course: you’re probably not going to be ready to start developing your own apps. But you will understand the concepts behind the technology. You will begin to understand the possibilities of technology. And most importantly, you will have gained the confidence that you can teach yourself anything you need to know about technology.

Technology is always changing but there are foundations and core concepts. Everyone who is successful in working with technology has learned how to learn on their own, how to teach themselves. And that’s all about a mindset and having habits of mind that help you to break down complexity. In this course, I’m going to help you learn to develop that mindset, how to develop those habits of learning. And that’s going to be very useful for you, not just in this course but in other courses and throughout your life.

So, if you worry this course is going to be too much for you: don’t think that. You can do this. And I’m here to help you. Even though this is a virtual course, we will have a lot of personal interaction online, including one-on-one conversations.

Let’s get started!


The No Code Movement

The no code movement views technological advances in software and artificial intelligence (AI) as opportunities for promoting user-friendly interfaces as alternatives for hand-coded programming.

That sounds great! Well designed tools allow people to focus on getting things done with software rather than being concerned with the details of coding.

But what if the tool is not well designed? What does well designed even mean? What if the very user-friendly tool restricts your creativity and constrains you to work within the limitation of the tool? How would you even know what limitations even exist?

Understanding the no code movement requires recognizing what is software?

What is the purpose of software? (I’ll refer to software and programs interchangeably.) How does software relate to coding?

Is a world of no code realistic?

Actually, we all use no code tools everyday, all the time. Yet, does that mean the end of coding?

Of course not.

There always will be new tools that improve on previous software. There always will be tools that not only improve on software that we use today, but tools that transforms how we work and live.

Developing those transformative tools require understanding the possibilities of code.

We need people to develop the code for those new tools. We need entrepreneurs to bring exciting ideas to market. And we need marketing professionals who understand how the possibilities translate to how we work and live. And we need leaders to carry forward the team efforts in creating new tools. So much of our lives and work are based in technology.

The challenge is to know when to use no code tools and when to dive into the code.


Learn JavaScript by Backwards Design

The focus on learning syntax of a programming language is one of my fundamental problems with the method that programming is often taught. I’m going to talk about an approach that works backwards from the desired result. This approach describes how to structure a course based not on the content you want to cover but on understanding the big questions and concepts behind the content. It’s called backwards design and is deeply explained in the book Understanding by Design.

The process starts by identifying what’s most worth understanding in the topic. That word–understanding–is loaded with meaning but also with ambiguity. In backwards design, you ask, “What does it mean to understand something?”, “What are the big ideas?”, “What are the essential questions?”.

Clarifying the answers to these questions uncover the key aspects, i.e., the blocks that serve as a foundation for building more knowledge on your own.

With technology, it seems that it’s always changing every day. Well, the specific implementations, the specific tools that we use do change very quickly. But the core components are quite solid.

One of the big differences, supposedly, of formal institutional-based education and an online course developed by someone on the Internet is the method of assessing the level of understanding. A lot of online courses give you the material and you’re own your own, often stuck in tutorial hell without feedback or further guidance. But I’m very curious as to how online courses can develop more engagement with students, more feedback, and more assessment that helps the students learn. Ultimately, that leads to more credibility for online learning and, perhaps, eventually, can resolve the biggest difference between institutional-based education and ad hoc individualized learning: credentials. Literally, the degree: the documentation that certifies you have learned something (supposedly).

Quality assessment is not about knowing syntax and facts but for you to demonstrate that you can apply what you have learned in a new situation. Can you go from the step-by-step instructions of a tutorial, and then implement variations of those concepts in a project of your own?

Actually, a person’s portfolio is the true measure of what one has learned.

A portfolio may not be only a series of projects but also a range of multimodal explanations that demonstrate you have absorbed the material and possess the capacity to remix it in creative ways. This multimodal material in a portfolio could be videos where you are explaining technology, could be websites that showcase your work, audio tracks that feature you discussing the concepts in a podcast, slides from a presentation, an essay exploring the limitations or effectiveness of a protocol. Your portfolio gathers selected artifacts of the knowledge you have constructed.

Too often in teaching, we have our learning outcomes, then set those aside and start figuring out how to slot copious amounts of content into those outcomes. With backwards design, you stay focused not on content but what leads to transferrable skills and what learning activities engages the student in demonstrating those skills.

For instance, a student learning JavaScript does not necessarily need to know how to flatMap an array. That comes later when the student realizes the need for it in a project. A student needs to have a solid grasp of foundational concepts like arrays and functions before struggling with more specific tasks. If the foundational concepts are solid, then the student should be able to figure out how to apply more complex features. Or, maybe the student will need to take a more advanced course, but you got to have a solid foundation before you start on the foundation of the next level.

The lens through which I view web technologies is always through storytelling.

It could be storytelling proper, as through interactive fiction, or it could be through data visualization, or branding, or ebooks, or interactive documentaries, or online games, or even through user experience. For me, personally, storytelling is a process that excites me. It’s my motivation for coding. So, when I teach beginning JavaScript, I teach it in the style of JavaScript for Interactive Storytelling. And I always put it in the context of the web.

That’s just me. That’s my thing. Other teachers take different approaches and that’s okay.

As an overarching structure, one can fall back to the reliable questions: who? what? where? when? why? and how?

I often teach journalism students, so that’s a familiar organizing principle to them. But I rearrange the order and expand the questions:

  • Why does the web exist?
  • Where does it come from? Where is it going?
  • Who created the web? Who develops websites? Who determines the future of the web?
  • When was the web created? When did it evolve into what it is today? When will the next major change take place on the web?
  • What will the web be like in 10 years, in 20 years, in 30 years? What was it like 10, 20, 30 years ago?

And wrapping it all together comes the how:

  • How do you create a website?
  • How do you create an interactive documentary on the web?
  • How do you create an online business?
  • How did this whole Internet thing all come about?

Unpacking all those questions is the life work of many people. These are the big ideas, the essential questions that drive web development at a conceptual level. There’s an entire other set of big ideas and questions that drive web development at a technical level. In a beginning course, students get a taste of those technical issues, and they gather enough skills to start their journey through technology by taking whatever path they want to further explore after the course.

For each of those questions, I’m going to breakdown the forms of understanding that identifies and prioritizes the type of content, exercises, and assignments needed in a course on web programming for beginners.


What is GitHub?

GitHub has become a key tool in not only my web development process but also in my life and work.

You definitely don’t need GitHub in order to create web sites, but it can really help you stay organized and productive.

GitHub, as the name suggests, is based on what was once a little-known set of software for synchronizing repositories of software code. Git, started in 2005, is an open source software system for version control of distributed code repositories. (I’ll leave explaining the details of git to another time.)

GitHub is a service layer built on top of git. GitHub was started in 2008 as a small startup. The popularity grew over time, and GitHub now has over 40 million users. In 2018 Microsoft purchased GitHub for $7.5 billion.

GitHub is not the only service of its type. There’s also GitLab, Bitbucket and a few others. I prefer GitHub, personally. I like its interface and additional features. (I’m not interested in debating the pros and cons of GitHub over another system.)

One of the aspects of GitHub I like best are its project management features, particularly issue tracking. Every repository on GitHub comes with a built-in issue tracking system, project management board, and even a wiki. These tools are very useful in any team-based project. But they are also really useful when just working in solitude on your own project.

You can even create a repository without any code and still use the project management tools. Plus, everyone now has the option to make their repositories public or private.

Another tool of GitHub that I emphasize in a course on learning to program is the ability for simple web publishing through GitHub. It’s incredibly easy to setup a website and start publishing your own HTML and CSS code.


Task list for initial prototype implementation

#4 in a series

What do you need to do?

The prototype shows you what you need to do. You then need to convert that into a list of tasks that you need to accomplish.

You can write the list as any kind of document. Don’t get stuck on figuring out the most fantastic task list app. Just write the stuff down.

What do you need to know?

As you create the task list, mark the items that you don’t yet know how to do. (It’s okay if that are all the items, but you probably know more than you realize.)

Initial tasks

For the zoonoses site I’m developing, here’s an initial list of tasks for getting started:

  • organize my file structure
  • setup the base files
  • implement a rough mockup in HTML/CSS based on the prototype sketch

Once you have this very rough prototype as actual site that you can work with, then start iterating. Add different elements. Build on each part incrementally. Before you know it, you’ll have a website.


GitHub as a Tool for Teams

Notes for DCI 190: Shenandoah, a studio course on online literary magazine design.

GitHub, based on the open source tool git, most often functions as a version control system. (There are several other similar tools based on git, such as GitLab and Bitbucket.) I tend to prefer GitHub, though the others are also very good systems and you may very well encounter those in whatever workplace you enter. Version control will be discussed later in the course. Initially, we’re going to focus on using GitHub as a collaboration tool, as a way of facilitating communication among the class, as a project management tool, and as a mechanism for tracking things to do in the publishing on a literary magazine.

If you do not yet have a GitHub account, then signup for one. You can get a free account at

GitHub Signup page

Don’t freak out by the Built for developers. You don’t have to be a developer to make really good use of GitHub.

In several ways, GitHub is a type of social network. I don’t really use it in that manner, but some people do. And your GitHub profile is public and serves as a good way of showcasing your technical work. Indeed, I’m a bit impressed when I see people place their GitHub address on their CV. You can see mine. Impressed? Uh, well, no? That’s okay. Let’s move on.

Jeff’s GitHub page

Once you have a GitHub account, send me your GitHub username. (Some of you have done that already.) So, what am I going to do with your username? This is where things start to get interesting.

The concept of a repository is central to understanding how GitHub works. Think of GitHub as being organized into repositories of code. Some of you may even be wondering, what really is code? In the simplest sense, code is just a set of files. Code could just be one file but it’s usually many files organized in a single top-level directory and, often, with subdirectories. It’s that top-level directory and all its files and subdirectories that make up a git repository.

Yet, in GitHub a repository also can have no code associated with it. Whoa. It’s not a very common case, but for the purposes of this class we’re going to use a repository on GitHub that has no code. So, for now, just don’t worry about any code. Instead, let’s focus on the other tools that come with a GitHub repository, namely Issues and Projects.

In this class, we will be working with the Shenandoah repository on GitHub, which you can find at This is a private repository. So, you’re not going to have access until I add your GitHub username to this repository.

There are three things I want to point out about the Shenandoah repository page: wludh, Issues, Projects.

All GitHub repository pages have a similar structure with a number of tabs along the top. But let’s first talk about that wludh up above those tabs. As students at W&L, you probably have guessed that wlu refers to Washington and Lee University. You might or might not have guessed that the dh refers to digital humanities. So, wludh is simply the organizational home on GitHub for DH projects at W&L. And the Shenandoah project is grouped under that organizational account. Enough about DH for now, but if you’re excited about that then you can browse our dedicated digital humanities at W&L site.


The way in which GitHub handles issues is one of my favorite features of this tool. What are issues? Ah, don’t get confused because this class is about publishing a literary magazine. In the context of GitHub, an issue is not an issue of the magazine. An issue is an idea, or a thought, or feedback, or a task to do. In the GitHub help, issues are explained under Managing your work on GitHub. That’s a really good section to read thoroughly.

Issues allow for threaded discussions so that you can follow the flow of a conversation. You also can add labels, tags, and milestones to issues. These attributes aid in organizing issues.

We’re going to use the GitHub issue tracking extensively in this course. Actually, issues will be one of the primary ways in which we communicate in this course.

Spend time getting familiar with the variety of ways in which issues can be used in GitHub. Many other tools have similar capabilities. Issue tracking is an essential component of project management. A well-structured set of issues enhances productivity for everyone. But it takes an organized mindset to use labels (i.e., categories) and tags in an effective way. Tools can only aid you so much.

Knowing how to conceptualize a structured approach to issue tracking via the logical use of labels is a skill that makes you a valuable part of any team.

I’ll be talking more in-depth about issues, but it all becomes clearer as you actually start using the issue tracking within GitHub. I’ve created some issues that will help you get started. There are three that I want to call to your attention.

  1. Q&A. This is a general issue where you can post questions throughout the term related to any aspect of the course, whether assignments or technical questions. I’ll also post my answers to those questions in this thread.
  2. Suggestions for enhancements/fixes. This week you should be looking through the online issues of Shenandoah and identifying enhancements and fixes for the site. We’re going to talk about those in class on Friday morning.
  3. Weekly reflection. A separate issue exists for each week of the course. (The dates are the Fridays on which the class meets.) Prior to class, post an individual reflection of what you learned this week. You’ll be doing these reflections for every week of the course. Essentially, this is a way to get you to think about your own thinking. It’s a good habit to get into for anything that you do. As for grading: the only way to get this wrong is not to do it. Your reflections will likely improve week-by-week.

I’ll talk about the Projects part of GitHub in another posting. Projects are directly connected to Issues. For now, focus on getting comfortable with issues.

To do:

  1. Signup for a free GitHub account
  2. Send me your GitHub username
  3. Look through Shenandoah and make suggestions in the issue tracker for enhancements and fixes.
  4. Write a weekly reflection in the issue tracker for this week.
  5. Let me know if you encounter any difficulties.

Teaching with GitHub

Several of my courses could benefit from a unit on GitHub. I want to devise a series of lessons that could be plugged into any of these courses with only a slight amount of modification specific to the actual course. It’s easy to identify the aspects of GitHub that I want to cover:

  • version control
  • code sharing
  • issue tracking
  • project management
  • public and private repositories

But I don’t want to start out course planning from a content coverage perspective. Increasingly, I’m trying to adopt an approach learned from Understanding by Design. It’s an approach that most closely mirrors my own approach towards my work and even my life.

This morning I jotted down several questions on a legal pad. I revised these into two essential questions:

  • What workflow is most supportive of collaborative development?
  • How can my choice of work methods enhance my productivity?

These questions place GitHub within the context of productive workflows, which explain why we’re even thinking of talking about it in the first place.

Getting organized is the first task for any development project, but in teaching coding, the introduction of GitHub is not the first step to learn. In helping students understand HTML/CSS, introducing GitHub too early could add a huge layer of confusion. I like for students to understand the simplicity of the web before they understand tools for enhancing productivity.


Interlitq: from custom PHP to WordPress

Earlier in the year I described the essential elements in redesigning a literary magazine with Interlitq as our case study. The Interlitq redesign continues. The current timeframe is a June completion date, which is delayed from my original intention of April. The delay is largely due to my teaching schedule. I completed the multimedia storytelling course, which had a complex web project, in April. And barely more than a week later started teaching an innovations in publishing course during our mini-spring term, which is just 4 weeks. Once spring term is over, I’ll have more time to wrap up the Interlitq project. Also, I have a graduate student from the University of Tennessee School of Information Sciences collaborating with me over the summer on literary magazine redesign and library publishing.


Let’s review the quantity of material that has been published in Interlitq since its origin in November 2007: 26 issues + 6 ongoing series. That represents over 500 contributors in a variety of genres (essays, interviews, poetry, fiction) as well as more than 20 artists contributing nearly 200 works of art for illustrating the publication.

Content Management

That amount of material requires a content management system (CMS). Since its beginnings in 2007, Interlitq has existed in a set of custom PHP files where each work (essay, interview, poem, story, etc.) was stored in a separate PHP file. Each contributor biography also existed in a separate file. While static sites offer significant advantages, the integration of content and code and style in this fashion is a nightmarish scenario for migrating to a new design and more efficient form of publishing. The Interlitq site consists of over 4,000 files that need migrating to a new system.

For the redesign, I chose WordPress for the CMS because of its broad level of support and customization. While a tool like Grav presented a lot of interesting possibilities, I simply wasn’t ready to jump into developing a Grav-based site considering the limited time availability I have for working on this project.


The Interlitq blog has existed separately on since the blog started. With this redesign we will be bringing the blog into same new design as the overall site. The blogging component gives WordPress another advantage since WP is a premier platform for blogging. And, honestly, another reason for choosing WP is that I’ve worked with it since 2004. So I’m very comfortable with the WordPress way.

New Design Aspects

Let’s look at a few new design aspects that will be appearing in Interlitq.


The previous design had a listing of past issues as show below.

The new design is a grid layout of issues and series represented by its distinctive artwork.

The CMS allows the grid to be automatically generated when a new issue or series is added.


One of the more problematic aspects of the old design is that the contributor list simply existed alongside the left column of the page. That worked fine for the first few issues but now with hundreds of contributors, the list scrolls far beyond the footer of the page:

A database-drive site allows for the contributor listings to be presented in a dynamic manner that features the author photo with the author’s name (which is actually a link to the author’s full bio on the site). This approach also allows optional text to exist below each author photo. For the prototype below, I simply added some placeholder text but this text could be a quote from the author’s work on Interlitq:

Obviously, this represents a small sample of the hundreds of authors that appear in Interlitq. The alphabetical row above the author photos allow for the contributor list to be segmented into smaller group for displaying on the page rather than loading the giant list all at once.



Interlitq: identifying essential elements in redesigning a literary magazine

The redesign of Interlitq is going extremely well. We’re on a timeline to have the redesign completed this spring, and aiming for an early April release if at all possible. A literary magazine is one of the more complex types of sites to redesign. On the surface it looks quite simple: modify the header, adjust the color palette, update the typography and call it done. But there’s much more once you dig into all the elements that make a literary magazine on the web.


In continuous publication now for over a decade, Interlitq has retained the same design since it began in 2007. Yes, that now looks very dated but there are aspects of that design that form Interlitq’s visual identity. And we don’t want to do away with that entirely. Rather, we want to strengthen certain aspects and create a fresher set of visual elements through typography and judicious use of white space.

My opening step in any redesign is to pull out some graph paper and a pencil. Then I start sketching ideas that seek to uncover the overall structure of the site. Some of the graph paper ends up crumbled and tossed to the corner of the desk. Eventually, I find some drafts that capture the essence of each page of a site.

The first element a person encounters upon entering the website is the header. Here’s the (almost) original header from 2007:

I say almost the original header since the site did not originally include a blog. The blog tab was added a couple of years after Interlitq started. But the coding for the blog tab in the header was programmed so that it also appeared in the header of earlier issues as well. One thing to note that is now a historical artifact of web design is that this header image actually consisted of 10 individual images, plus 14 spacer gifs, all set within an HTML table. Actually, it’s an HTML table within a table. That was the complexity of web design in the early 2000s! But it looked good for the time, and it worked. Yet, there was something about the branding that wasn’t clear, e.g., was the site named Interlitq (or interLitQ) or was it The International Literary Quarterly? Or was The International Literary Quarterly a subtitle or simply a description of the site?

In 2010 a new header was designed for the site that solidified the branding on Interlitq as an original and memorable brand for the site. And the new header retained the thematic color scheme of the original.

The result was a slimmer header with a clearer emphasis on the Interlitq brand. This header still had the same problem, though, of being built out of multiple images. In the code the images have unwieldy filenames likeĀ menu_r1_c2a.gif.Ā  Here are examples of a couple of individual images that comprise the header:

Dealing with multiple images in a header menu is a technique of the past thanks to advances in CSS, the coding language used to style web pages.

I knew that any redesign needed to start with figuring out how to design the menu in CSS without using any images. Only the web tech readers of this post will realize how exciting that is! And, also, how important. Through using only text-based CSS in styling the header, then we can create a site that works well on all types of screens, including cell phones.

The new header uses no images and consists only of code. (Okay, for the simplicity of writing this post, I’m cheating a bit by using a screenshot of the new header but, believe me, it’s all code and looks very crisp and clear on the actual site.)

The entire header and menu is created through CSS, including the rounded corners on the lower edges and the slight shadow. The color palette has been updated and the type is all web-based.

One of the remarkable aspects of web development that enable non-image based design are web fonts. For Interlitq I chose two fonts from the freely available Google web fonts service: Cormorant Garamond and Lato. In the header, the word “Interlitq” is set in Cormorant Garamond and the text of the menu is set in Lato.

Home page and landing pages

The home page of a literary magazine, the web page you see when you enter the main address of the site, e.g.,, often serves multiple functions. In the early years of Interlitq, the home page served as the introduction to each issue. At that time, Interlitq only published issues quarterly. Below is a screenshot of the very first home page for Interlitq, which also was Issue 1 in November 2007.

That page was really functional. The main text on the page was an introduction by the editor. A list of contributors appeared in the left side column and the masthead just underneath the contributor list. (Again, note that the header menu in the image above is the only part that differed slightly.) Though information about each author’s work is embedded in the editor’s introductory text, one essential element that is missing is a table of contents for the issue.

The home page for issues of Interlitq has been redesigned to the following layout:

Noticeable changes here is an emphasis on an actual table of contents that gives prominence to the work of each author. The titles are the works are displayed as hyperlinks next to the authors. The works also are grouped by genre.

The next post in discussing this redesign in progress will examine how to handle the home page when the literary magazine switches from issues to publishing individual works on an irregular basis. That presents some challenges but can be handled quite well.