- general tips
- An excellent collection of advice from Jason Hong
- Tomorrow's Professor (also includes advice on transitions such as how where and why to get good recommendation letters).
- Lots of tips
- Dave Patterson's lecture on How to Have a Bad Research Career
- Other people in other fields express their professionalism by doing things such as wearing suits. In our field it is the quality of the research, and of the presentation of that research that we use to represent ourselves
- Research, without the ability to communicate it, may as well have never been done.
- References should be consistantly formatted (for example, all author names and all occurrences of the same conference should be formatted the same way, all conference papers should be formatted the same way, same with journal papers, tech reports, and so on). References should meet basic standards for "normal" formatting in our community (for example, journals are typically cited with the format volume(issue):pages). Years should always be listed in the same place. If you use latex or word you should use the corresponding facilities (bibtex or cross referencing, preferably combined with Endnote) to ensure that your references are automatically updated when one is added or deleted. References should also be sorted alphabetically. More details can be found in a good grammar guide such as "The elements of style" (see last point below).
- The document should be proof-read before being handed to me. This doesn't mean it needs to be perfect. However, spelling errors should be caught, major grammar errors should be caught, colloquialisms and contractions should be removed, hyphenation should be consistant, and latin (etc., e.g., et al., and so on) should be italicized and include the correct punctuation.
- The document should be in the standard conference format, for whatever conference you are submitting to.
- Read "The elements of style," by William Strunk, Jr. (An early edition without the insight of E.B. White is available at http://www.bartleby.com/141/strunk1.html). 4th ed. Boston : Allyn and Bacon, c1999. xviii, 105 p. This covers many of the issues above, including how to format references, etc. Some other writing resources: http://newark.rutgers.edu/~jlynch/Writing/links.html
The above list may seem daunting and unecessary, after all the work that went in to the actual content of a paper. You may even think, after having worked with me on a paper, that I am too much of a perfectionist. It is not unecessary, although it does take time. I do have high standards. However, refer back to my comment on professionalism. Papers submitted to conferences should be ready to publish. This is crucial to understand. The impression you make on reviewers depends in large part on meeting this bar.In addition to the above issues, here are some writing tips. The following things should be done from draft 1:
- Start with an outline.
- Don't worry about everything making sense. Just write!
- Be as detailed as possible. A paper is a user interface that must support walk-up-and-use people who have never seen that exact subject matter before. Explain things to them
- Put drafts of figures in -- these can be ascii drawings, so long as something is there.
- When you get comments from me, if you choose not to address them in the paper, write a response or an explanation for why not. Or discuss them with me in person.
The following is a tip that you will learn to incorporate over time, but should not be a focus in your early drafts. This tip is an easy fix later on, and likely to cause writer's block if applied to early:
Say what you're going to say, say it, and then say that you said it. Another piece of advice is that every unit from the entire paper down to each paragraph should have that structure. I should be able to look at just the abstract and get a sense of the whole paper. I should be able to look at the first paragraph of each section to get a sense of what the section is about. I should be able to look at the first sentence of each paragraph and learn what the paragraph is about.
Another tip I just found myself writing down in response to a paper I just read: My rule of thumb for related work is only say as much as you have to. That means that you only describe something in detail if (a) understanding it is key to understanding your paper or (b) a reviewer might question how much your work differs from the work you cited. Otherwise, you need to practice the skill of summarizing why it's relevant without explaining the whole system. Careful not to simply say *that* it's interesting though.Some other advice
- Define terms such as user/designer vs end user, and use consistently
- Find first instance of phrase "GUI support" and make sure it's defined.
- check capitalization in headings
- spell check
- make sure explicitly to spell check and read figure captions since sometimes these are ignored through many iterations of the paper.
- check for correct use of hyphens. This problem can be fixed by searching for "-" and writing down everything that's hyphenated, then searching for those same things without hyphens. Need to then pick whether to hyphenate or not and make each one consistent. However, I typically also keep a list of things I do or don't hyphenate that are often done wrong (e.g. here are some from my thesis:
- check for correct use of we
- search for "In order..." and decide in each case whether to keep it (it doesn't add any content to a sentence)
- search for "the fact that", remove
- get rid of "they do..." (users, systems,etc should be singular)
- search for don't, can't, and other contractions and remove them
- search for ' and make sure that it's used correctly (e.g. its vs it's)
- check that e.g. etc. et al. and so on are correctly spelled, capitalized and italicized
- check for split infinitives
- avoid sentences ending in prepositions
- correct use of us
- which --> that
- look up possible vs potential
- look up capabilities vs abilities
- For example --> an example of what?
- tense should be consistent within a paragraph
- First, it's important to actually read these. That's the only way to catch capitalization errors in the name of systems and other problems with titles or names (for example, I caught a reference in the paper that prompted this message that listed anind as D. Dey. Only reading the references makes it possible to catch these sorts of errors. Any time you have a question, you should go to the source (e.g. the ACM Digital library) and check what's right.
- Second spell check the references (really you're checking the titles)
- Third make sure every paper has page numbers
- Be consistent across conferences and within conferences about how you name them. For example, normal would be something like "In Proceedings of the ACM Conference on ... (CHI YEAR)" where year is a 4 digit year of publication. CHI extended abstracts should probably be In Extended Abstracts of the ACM Conference on ... Similarly, UIST would be "Proceedings of the ACM Symposium..." and have the year added as well. for other conferences, we might consider adding "Proceedings of the" before their names. In contrast, I believe that Transactions on Computer Graphics (or any of the Transactions journals) do not have ACM before their name. If you have any questions, go to the source. E.g. I found NordiCHI in the paper that prompted this message. Is that right or is it NordCHI? I'd have to look to know.
- It's common to put the volume of journals in bold and the pages after a colon. (e.g. 43(4):42-45) would be volume(issue):pages).
- Outside of system names, there's less consistency in what to capitalize. For example, do you capitalize the word after a colon or not? I suggest just making sure you're consistent.
- Might want to capitalize the first word after the colon in the Phidgets reference, for consistency
How do you find important papers for a topic you're interested in? First, you need to figure out the right "keywords". You do this by searching for papers with different keywords until you find at least one paper that's relevant. That's all you need.
Next, you need to figure out how to find other similar papers. Look at the keywords in the paper, write down the ones that relate to your problem. You can use them to search for other papers. Look for the author's home page. Figure out who the authors are. Who did which part of the work? Who is the advisor, who are students or collaborators? What are the research areas of these people? Likely, one or more of them will have other relevant publications.
Finally, trace the tree. Any decent papers will reference other relevant work. You can find this by looking at the reference section at the end of the paper. Also, many papers (especially if they are older) will be referenced by other work. You can find referring papers using what's called a citation index. Comprehensive citation indexes can be found in libraries (there's a link to an online one below).
You also want to find the actual text of papers, rather than just the reference and abstract info. These days, in computer science, you rarely need to go to the library. If a search at one of the sites below doesn't turn the paper up, try looking for the home pages of authors. They usually have an electronic copy available (or might be willing to email one to you if you ask).
- The DBLP bibliography server. Search for "DBLP" and the name of a paper or an author in google, and you'll get a link to a page that has the complete reference and links straight to the digital library (e.g. ACM DL) that holds the pub.
- Very complete set of bibliographies (even mirrors HCIbib, etc.)
- ACM digital library (ask me if you need a way to access this)
- A great Citation Index, also see: A graph visualization of the same
- Thoughts by Gail Kaiser on how to search for related work
- Data from research in Social Science
- Cal's data repository
- More Socio-metric information including the Social Science Electronic Data Library
- UCSD's Data on the Net site.
- Gallup Polls
- An index of old web pages
One important first step here is to determine quickly whether and how deeply you should read a paper. Skimming is an important skill. Start with the title, then the abstract. Then jump to the conclusions. If you're still interested, read the introduction, and if you need more details, only then do you actually read the paper.
If you get to this stage, always write up your thoughts in a summary, and keep a copy of the paper on file. The links below really do a good job of telling you how to write such a summary. Just remember, as you read papers in your field, you are trying to build up not only an understanding of each paper, but also an understanding of the landscape in which they sit. Who are the authors? Have they done groundbreaking work in this area, contributed incremental next steps, or are they perhaps just starting out (maybe they're still students). What about this paper? Is it groundbreaking now? Was it groundbreaking when it was published? Why would someone want to read it?
One last point: if you are doing research, you are looking for the gaps in the field. Every paper has a future work section that suggests possible gaps. Have they been filled in? Do any of them spark your imagination?. You can also think about a paper as suggesting a lense through which to view things. If you read a paper about cscw, and are working on an ambient display project, think about how the issues raised in the cscw paper might apply to ambient displays. The reverse applies too of course. A lense like this can also help to identify gaps, things that need to be explored and discussed.
- How to review a technical paper
- Guidelines for reviewing manuscripts (for acceptance/rejection)
- How to review conference and journal papers for acceptance/rejcetion
- Guidelines for critical analysis of journal articles (the site is full of useful handouts )
- How to read a research paper
Do you know about other research groups working in your area and where you and your work fits in? Some of this can be found by reading related work, some of it through conferences. Variously in the past, I've been part of groups that keep a web page of relevant conferences/journals (this helps suggest where to publish/look), make web pages of related work, and write literature reviews of related work that try to address these sorts of things. In the end you build up a picture in your head that is sort of a graph of people and projects and who spawned/taught what and moved where. This is also what you'll be doing for the field of HCI in general as you prepare for your qualifiers.
This kind of process is an important form of networking, background research for a PhD thesis, and generally benefits research. Once you've done this, you know who to try to meet at conferences, where to look for possible new work, and when you want to, say, sponsor a workshop on a topic, or find a summer internship, you've got the right contacts/people to invite. And it helps you to see where your own work fits in and how it is different. Always think about papers from this perspective as you read them.HCI Bib and other links mentioned above on this page to discussion and mailing lists. In particular, you should consider joining CHI-STUDENTS, CHI-ANNOUNCEMENTS, and ACM in order to stay in touch with your larger research community.
- Advice on Mentoring
- The CRA has a number of great programs, including a news letter (the Computing Research News, sign up by sending a request to email@example.com) and the CRA bulletin, sign up by emailing firstname.lastname@example.org with "subscribe cra_b"). CRAW also has lots of great mentoring programs for women, from an excellent workshop that you should attend in your first year if you're a new faculty member to funding for undergraduate internships and research involving female and minority undergraduates.
- The CRA also has some great write ups on time management, getting tenure, building a research career, obtaining federal funding, networking, teaching, and more.