Okay, I'm very happy now to introduce a dynamic husband and wife duo, Gerald, Gerald Graff and Kathy Bergenstein. Gerald Graff is Professor of English and Education at the University of Illinois, Chicago, and in 2008 was President of the MLA. I think, did he directly follow Bob, or closely followed Bob, almost. Was Mary Pratt between you? Okay, anyway he has had a major impact on teachers through such books as professing literature and institutional history beyond the culture wars, how to each the conflicts can revitalize American education. And most recently, and the book that I mentioned before, which I love, Clueless in Academe, how schooling obscures the life of the mind. Kathy Bergenstein is a lecturer in English at the University of Illinois, Chicago, who is published on writing in college English and with Gerald Graff in the Chronicle of Higher Education, Academe, College Composition and Communication, and the recent book, and essay, A Progressive Case for Educational Standards and How Not to Respond for Common Standards in Literary Study, Measurement in the Sublime, Disciplinary Assessment. They, of course, are also authors just a second. Since I want to do equal opportunity book plugs. They say, I say. And together Gerald and Kathy have given talks and workshops at numerous colleges and are currently working on book tentatively entitled One Size Does Fit All, How Argument Can Unify and Save American Education. Thank you very much. Thank you, Les. Let's face it, folks. When it comes to writing, most of our students are pretty confused. And this confusion, which we think is one of the most under-recognized and under-discussed problems in American education, stems not from any fault of the students themselves, but from the fact that as they move through the American educational system, these students receive no consistent picture of what they're supposed to do when asked to write. Instead, they're presented with a set of wildly mixed messages about writing as they go from elementary to secondary school and from secondary school to college if they make it to college. Despite much current insistence on the importance of college readiness and considerable sums of money invested in college prep services, there remains a confusing disconnect between high school and college writing, with high school writing assignments often bearing little resemblance to what's expected in college. This disconnect arises because high schools are uncertain how to prepare their students to write in college, and they're uncertain because we in the colleges have no agreed-on conception of what college-ready writing looks like that we can pass on to the schools. As a result, it shouldn't be surprising that once students get to college, the confusingly mixed messages about writing that they have received in primary and secondary school only further multiply as undergraduates go from course to course, discipline to teacher, discipline to discipline and teacher to teacher, even within the same discipline. One example of these mixed messages would be sort of simple, basic fundamental issues like are you supposed to have an argument or not in an academic paper? Students have told me about teachers who were given them a low grade and have said because they just summarized what they were reading, the teacher will say, hey, I've read the book. I want to know what you think. What's your argument? Right? We do that. But then the same student will go to another teacher who will say, well, I don't care what you think. I want to know if you've read the book. Names on request of teachers. I know who said that. And so I realize at some point that this was a big reason why students are always coming up to us and saying, on this paper, do you want my ideas or just a summary of the reading? Even in first year composition programs, which in theory prepare students for the writing assignments they will do in the remainder of their college careers, it's not uncommon for students to receive contradictory advice from different instructors and I think WAC programs suffer from that same syndrome frequently. Furthermore, there's usually so little connection between first year writing and subsequent academic writing that recent researchers on the problem of so-called transfer find that the writing skills students practice in freshman composition generally do not transfer to other disciplines and courses and that in fact few students even expect that they will. This mixed message curriculum, which is what I've called it, is an unnoticed cause of the achievement gap between the academic haves and the have nots of our culture. For the small minority of high achieving students manages to synthesize the curricular mixed messages and thereby enter into the intellectual conversation of the faculty, but the great majority don't. Instead of entering the Burkean parlor of the intellectual world, those in this student majority who do manage to get by and graduate tend to do so by the familiar practice of psyching out their successive teachers as they come and giving each of us whatever he or she seems to want, right? Even when it's contradictory. Since these students can't count on anything they learn in one course having any validity in the next course or the next, I mean how could they since we as instructors aren't even aware of what our colleagues are doing generally, at least true in my case. Since these students can't count on anything they learn in one course having any validity in the next course of the next, they virtually have to start over again from scratch in every new course with no, their education has no cumulative dimension. Because the mixed message curriculum is the only one most students ever experience, they quietly adapt to it and accept it as perfectly normal. And so in our way do we as teachers, we who are so insulated from each other by our classroom walls that we're able to ignore the fact that the writing wisdom we dispense in the morning may well be negated by a colleague after lunch. The privatized classroom space that we like to romanticize protects us from recognizing that in effect, we're often fighting one another and canceling out each other's lessons. I'd have to say with all due respect to Professor Lane this morning, I don't think our new online, I think we're missing a big opportunity with online technology to help dissolve the boundaries between courses. If anything, I think the technology tends to shore them up, rigidify them even further in the way we're using it. In the face of the confusion that this mixed message curriculum inflicts on students, it's not helping matters at all, we think, that a prominent recent trend in the rhetoric and composition field glorifies rhetorical and linguistic diversity, contingency, and multiplicity. According to this view, it's important to teach a variety of writing genres and to stress that all writing is contingent, that it depends not on any common set of principles that can be reinforced program or system-wide, but on the particular situation or context of the writer, the unique action she seeks to perform or the particular audience she addresses. This particularist view of writing, which denies the existence of common rhetorical principles across the genre, is reinforced by a recent research trend in colleges of education and I think elsewhere, which a trend which holds that academic skills are discipline-specific. We don't believe they at all are. Finally, the particularist outlook is encouraged in today's wider educational climate, where standardized education, the word standardized is synonymous with bad, dead, oppressive, and so forth, and where a maxim that is widely genuflected to is that no one-size-fits-all model can possibly do justice to the complexity and diversity of our subjects, students, and educational institutions. What Gerald and I would like to do today is make the case for a standardized writing curriculum. Not the bad standardized test or SAT tests, Les Perlman here at MIT, has rightly criticized, nor the no-child left behind type of standardization, which so many others have rightly taken to task, but a type of standardized writing curriculum that does not yet exist. For Jerry and me, the view that no one writing-size model or method can possibly do justice to the many different students, disciplines, or courses we teach is just wrong. Our view is that the academic world is far more regularized. In other words, it's far more standardized. We all do a lot more of the same things than most of us recognize. Despite the rich diversity in what we all believe is academics, most effective academics rely on a stock or an arsenal of common argumentative forms to structure their beliefs that cut across all the academic disciplines and that faculty need to focus on to a far greater extent if we hope to counteract the negative effects of what Gerald just identified as the mixed message curriculum that is currently plaguing the U.S. educational system. In our view, the best way to counteract students' current confusion about writing is by faculty getting their act together as a collectivity and by offering students a far more consistent, uniform, regularized, non-disjunctive vision of writing. One that is comprehensive enough to encompass all the different types of writing that students will be called upon to do, and yet at the same time, simple enough to students to hold on to as they move from course to course. But how do we arrive at this? How do we induce faculties across the board in all different academic disciplines to get on the same page? In our view, a minimal first step involves getting faculties talking more within and across disciplines about what constitutes academic discourse. Is there one academic discourse or are there many academic discourses? And if there is just one meta or grand academic discourse, what does it look like? And how do we teach it? And how can administrators create more common ground among teaching staffs without resorting to top-down autocratic authoritarian dictates and the resulting bad morale? Getting faculties talking more, just talking more about these issues would be a productive, about these questions would be a productive first step. But Jerry and I also have a more ambitious solution, and that is for everybody just to agree with us. In all seriousness though, we want to resolve these questions that I've just raised by persuading faculties that a common academic discourse already is in use, that there is a core of writing and thinking practices common to all the academic disciplines and their different modes and genres of writing, that there's a meta-discourse or meta-genre underlying all of the different academic disciplines and even the different rhetorical genres. It's sort of there's a superficial, there's superficial differences, but underlying there's this sort of common underlying argumentative game that everybody's playing. At least most effective academics are playing it. Indeed, an emerging consensus on the existence of these common meta-discursive practices is suggested by the popularity of the term critical thinking skills which is seen as transcending the boundaries between the disciplines and even between the academic world and the worlds of work and public citizenship. This is in no way of course to deny that there are many important differences between the discourses of the humanities and the sciences or between the diverse subfields within each discipline that a lab report say has different characteristics from a philosophy or a literature essay or a sociological survey. It is however to say that despite these differences, these obvious differences, there exists a set of shared rhetorical practices common to them all, that all the disciplines and sub-disciplines play a version of the same underlying game. That is, despite these disciplinary differences, there is no discipline in which one doesn't say or in which one should not say. Many in my field believe blank. My own view is blank. What's more, we believe that this common argumentative underlying game can be identified rather simply and almost reduced to a recipe. It's kind of the game of dialecticism or it's a sort of dialogical game. It involves entering a conversation, listening to what others are saying, summarizing what those others are saying in a recognizable way and making your own argument as a response. Basically, this is the one big move that all effective academics make and it boils down to a dialogical process of summary and response. That's it. That's all there is. Though admittedly, all else is pretty big. There's a lot to it. What is striking to us about this short list of fundamental argumentative skills that we believe all instructors should be coordinating with each other on and reinforcing in their classrooms is that this short list is precisely the short list of skills that most of our students are failing to master. What is also striking to us about this short list is that this short list of fundamental skills are so unevenly or so unevenly highlighted in today's educational system that many students are not even aware that they are supposed to master this short list of fundamental skills involving summary and response. In other words, it just doesn't even come into view for most students. They just go from course to course and they don't even see this. They don't even see these skills of summary and response as important to their education. No matter how much expertise students may gain in their majors by the end of their college careers, no matter how much knowledge they may gain and no matter how much expertise they may gain, they are often so inexperienced in the use of a basic critical thinking move like, although many in my field believe blank. I would argue blank that even upon graduation, they are often unable to effectively communicate that hard-earned expertise to others. In our view, students have the ability to do much better if only faculties could get their act together, not as individuals, but as a group, coordinating their lessons as the collectivity that they are. And this is not just a matter of more faculty or even all faculty teaching writing, which is what it seems like a lot of people just want, you know, oh, if everybody could just teach writing, wouldn't that be great if we could get all faculty teaching writing? Well, to Jerry and me, that's not just the sort of be all end all solution to everything because if everybody just starts teaching writing but doesn't start teaching writing in the same way or if we teach writing in different ways or in ways that may be similar but students can't recognize as similar, if we don't speak a similar language to students, it's just going to confuse students. So for us, what's really important is that everybody start teaching writing across the curriculum but teach writing in some sort of similar, redundant way or at least the way that students can recognize as similar and redundant. In other words, students would more readily master the basic skills of critical thinking and writing, of academic and public sphere literacy. If these basics were, we shudder to say, at standardized across all domains and levels, that is represented with enough redundancy, consistency and transparency so that students could recognize them as fundamentals rather than as one instructor's arbitrary preferences among many competing for their attention. What happens when Jerry and I have our students will come into our class even if we're teaching like a freshman, a first year composition course and they'll be like, you know, what we end up having to do is we have to sort of, it's not just that our students come into our classes as sort of tabula rosses not knowing the skills that we want to teach them. It's that they have actually been given advice from other teachers that we have to say, at least in our best judgment, to unlearn that advice. But it's our credentials against theirs, against the other teachers. And sometimes it's not even that we necessarily want to contradict the other teachers. It's that our way of expressing what we want, what lessons that we want to give to the students, sounds different to the students. Because we will say it in a different way or we're just, it doesn't sound like we're on the same page with the other faculty even though if we probably got in the same room with the faculty, we probably would have similar lessons. But it sounds different to the students. So it sounds like the students have to, from the students' perception, they have to unlearn in our class what they learned in their previous educations. And they also, it seems to them, have to unlearn, they have to bracket what they're learning simultaneously in their other college courses when they're in our course. And it's sort of, it's like we're working at cross purposes with the other faculty rather than working in tandem. It's like a kind of broken dysfunctional family. It's like the students are in a kind of broken down institution as they move from course to course and at all levels of the academic educational system in the United States. To master academic writing, which we all know is complex and difficult enough in its own right, what students need is repeatedly reinforced instruction in how to summarize and make an argument, not just in first year composition courses, but in courses across the board from elementary school to college. Paradoxically, we would argue, students who learn these fundamentals will eventually be able to adapt to the multiple contingencies and complexities of writing. Then will students who are now too prematurely exposed to those contingencies and complexities before they have acquired the verbal and rhetorical tools for assimilating them? We can't emphasize, we can't emphasize too strongly that the common ground we're referring to in academia's argumentative practices is not something that we are trying to conjure into existence, much less have imposed from the top down something that never works, but rather something that's already in existence but hidden from view, hidden from view, especially by the mixed message curriculum. That is, despite academia's highly diverse and often conflicted beliefs, academics, at least competent ones, keep engaging in the same types of intellectual behavior over and over. We're sort of doing a lot of these right here. Indeed, we're never more illustrating our common ground than when we're differing with each other, when we're arguing with each other, when we're exposing our differences. In this respect, there's an important sense in which as academics we're already on the same page, but the disconnections of the curriculum are hiding this commonality from our students and ultimately from ourselves. So we would argue that our primary argumentative moves are so commonly shared and so repetitively recycled over and over that they can readily be reduced to a set of conventional formulas and we sort of all know them. We all take those in. They're so familiar, they become so familiar to us that we hardly notice them, except when it becomes shockingly clear that our students don't control them and are baffled by them or intimidated. Consider the basic move that Kathy described of entering an academic conversation by summarizing what others in the field have said in order to motivate our own arguments, moves whose variants we represent in argument templates that run throughout they say I say, which is the title of which is itself kind of the ERR template. Textbooks, by the way, not even to mention books are themselves a form of standardization. We don't think about that very much, but I think we should. You need to just kind of defamiliarize the notion of standardization. And they say I say, I guess, is a kind of hyper super standardization and it pushes the standardization to the point of templatizing what in fact, we all I think in our brains have reduced to templates formulas. We sort of see this as our self-glorifying way as being not with the bad guys who are trying to turn everybody into robots, machines, but with the good guys like Walter Benjamin. That is, we see writing templates as an example of Benjamin's work of art in the age of mechanical reproduction. They are mechanical reproduction in the practice of writing, which Benjamin of course is not as elitist or conservative, but as a form of democratization. He celebrates in that essay. Anyway, some of the templates, template formulas in our book are sort of the standard moves that we all make all the time, but that the students don't easily make and as Kathy said, don't even often know that they're supposed to make. Though it's become fashionable today to assume that blank, the truth is that blank, my own view is blank. X argues blank and I agree because blank. On the surface, this text suggests blank, but a closer analysis shows where would literary critics be without that one? I used to think that blank, having read blank however, I now see that blank. X argues blank and I have mixed feelings about it. On the one hand blank, on the other hand blank. X can't have it both ways. At the same time she says blank, she also says blank. Although fierce debates have raged over blank, the opponents all share a common commitment to blank that they may not recognize. Until now I've been suggesting that blank, but it's really more complicated. People who sometimes criticize us are saying, oh come on, templates are so reductive, inherently reductive, they can't possibly do justice to the complication of academic discourse and writing. But of course, there are templates for complication. We all use them. It's more complicated than that. Allow me to problematize what you just said. These are formulas. Academics who are good at complicating need to do so through using certain formulas. At this point you will probably object that. We all probably agree that blank. Where agreement ends, however, is on blank. How could you begin, many essays could not begin without that formula, at least very useful that they can. In presenting these formulas in the book, we were following the lead of granting agencies and journal editors in both the humanities and the sciences who often recognized that such formulas are the most efficient way to get grant applicants and article writers to come out from behind their protective cover and actually explain the essence of their projects, right? Thus in its application form for its postdoctoral fellowship, the National Academy of Education, located at Harvard, actually has a template in its application form, as many grant applications do. Applicants for the postdoctoral fellowship, the NAE, are asked to complete the following formula in 50 words or fewer. Most scholars in the field now believe blank. As a result of my study, blank. And then nature, the leading journal in the biological sciences, you can go on their webpage, both these organizations, you can go on their webpage, ask prospective contributors to follow a similar formula. It's given in a link entitled How to Construct a Nature Summary Paragraph. And part of it says, make sure you, if you're submitting an article to us, include two or three sentences explaining what the main result of your research reveals in direct comparison to what was thought to be the case previously or how your result will add to previous knowledge. And again, it's people in the field have tended to believe X, I show Y. Again, these examples for us are powerful evidence of a common game that competent academics play, though it's interesting that they have, the editors feel they have to give them. That is, they are also evidence that even experienced faculty members and graduate students often need to be reminded of how to play this game. They need help on how to play it when they apply for a grant or write for publication. And if even we advanced academics sometimes need such help, it would seem that the least we can do is to provide similar help to high school and college students. Again, the least we could do is to try to represent for students much more of our common ground that we now do. Providing such help was again, precisely the point of the argument templates in our book, which are an effort to produce accessible models of sophisticated argument, argumentative moves that will be easy for teachers to replicate and for students to spot in their reading and use in their writing. The templates represent our attempt to supply students on a mass scale with that consistent and usable picture of academic writing that according to what it says here anyway, students are not getting. In conclusion then, what Jerry and I have been advocating today is a standardized writing curriculum, something we know is not the most popular idea among academics. Indeed, what we have been pushing for might even be thought of as a double standardization and that the type of basic argumentative skills that Jerry and I believe should be taught in colleges, should we believe also be taught with appropriate modifications in the schools, a proposal that will no doubt get us into double trouble with many of our friends and colleagues. We are sure we don't have to tell most of you sitting here today that among academics, both conservative and progressive alike, educational standardization is almost a totally pejorative term. One that seems incompatible with such sacred ideals as the private, almost personal space of the classroom, and that conjures up images of administrators or even outside political bodies trampling on our cherished academic freedom, forcing us to discard our years of training and teach to what some bean counter says we should teach. Especially today with the adjunctification and casualization of academic labor, calling for a standardized curriculum seems almost blasphemous. The concern that adjuncts, and I myself him one, with few protections will be asked to bear the burden of any standardization proposals in the realm of higher education and do most of the dirty work of forfeiting their classroom autonomy is a genuine, legitimate fear. I fear it. Yet while these concerns about educational standardization are serious, Gerald and I have tried to approach the issue from a different angle, asking not just about what is convenient and right and just for faculty, although that is a major concern. It's a multifaceted issue. It's not just a one-sided issue, so we can see that it's a very well-rounded issue, but we wanna ask just not about what, not just about what's convenient and just and right for faculty, but also about how to help allay the confusion of student writers. We wanna look at it from the student's perspective as well. Our central question has been not just will the teachers have to change what we teach, but how can we help, how can we as teachers help students penetrate our mysteries and learn to communicate more effectively, gaining basic literacy skills that given the current disconnection that characterizes the US educational system, they are failing to master in overwhelmingly unacceptable numbers. Ultimately, what Gerald and I have tried to do is challenge the pervasive assumption that every teacher or student is different, that every course or discipline is different, and that therefore it's fine if students get a different message in every course, if the commonality that exists in their courses is obscured, and if students are consequently forced to start over from scratch each time they encounter a new instructor. What we have tried to show here today is that there is far more regularity in what academics do, or at least in what most effective academics do, and how they talk, write, and argue than has thus far been appreciated, and that if we hope to teach students to play our academic game, or if we hope as Robert Scholes suggested just earlier here today, just to get students to write in general more effectively, which I think is a very laudable goal, obviously, that the two writing academically for us and writing in general, those aren't incompatible at all, very commensurate goals. We need to identify these moves clearly for them and present these moves in more consistent and even redundant ways. So whenever anyone says that when it comes to writing no one size fits all, our response is, well, actually it does. Thank you. I'd like to introduce now Chris Anson, who is Distinguished Teaching Professor at North Carolina State University, and is Assistant Chair of the Conference on College Composition and Communication, which means that the Associate Chair next year and Full Chair the year after that, the year that the conference is in Las Vegas. And you can make of that what you want, although I want him to give the chair's address as an Elvis inviator. Chris has written how many books? A lot. A lot of articles. He's consulted for scores of universities and all over the world. He's a dynamic speaker, educator, and again, someone who's done workshops and teaching as well as a prolific publisher and writing in all certain, and I think a polyglot in terms of all the different genres and fields of writing pedagogy that he has written about. Chris Anson. Thank you, Les. It's an honor to be here and nice to be in a place where the prospect of snow doesn't cancel the symposium two days before it's supposed to take place so that people can go rid the shelves of bread and milk and wine. As my grown son would say, talking about the implications of the digital revolution on our society is so like 2005. But there's clearly much more to do, I think, to understand what's happening with our students, what's happening to the acquisition of literacy and now multiple literacies, and what affects any of that is having on good old academic discourse, the kind that's sort of in the bones of those of us here. So I wanna spend some time reflecting further on the relationship between academic literacy and what I'm gonna call borrowing the term from Kevin Rusen and other scholars, vernacular literacies. These are self-sponsored, informally learned literate activities that are typically practiced outside of academia, because it seems to me that resistance to new forms of communication, even in the most traditional spaces of the academy is now futile. And the tools, the devices, the channels, the media for these expanding forms of communication and knowledge trends for continue to explode. So we can't ignore them if we wanna figure out how to support the development of advanced academic literacies. And I think we often have to remind ourselves that digital technologies have stimulated unprecedented amounts of writing within and across communities that before the advent of the internet used writing painstakingly and infrequently. Take one example, penpal writing. Penpal writing was first advocated in the 1940s. Actually, it was advocated by Parker Penns in 19... In the, you see the relationship there, right? And at the 1948 World's Fair, it had a slow uptake, but it soon spread and eventually in the schools. The U.S. Postal Service later on gave the idea boost by subsidizing mail costs in a program called eventually called PS Right Soon, which was co-sponsored by the National Council of Teachers of English. So in the 1950s, international penpal letters between students were sent by ship or less affordably by prop planes like the Boeing Stratocruiser, a state-of-the-art transatlantic aircraft which traveled at the astonishing cruise speed of 301 miles an hour, took 16 hours to get from New York to London. Anybody been on a Stratocruiser? I have, I was four. They tell me I was better behaved than I probably would be now for 16 hours on that trip. And once the mail hit the ground, it then went by land. So most pen pals managed a couple of letters back and forth in a few months, written on that thin, weightless paper that folded into an envelope. Hardly a very interactive or writing-rich experience. Now it's possible for a 10th grader, say, at East Boston High School, to send a note to an e-pal in Singapore in, let's just say it'll get there by breakfast. So what was once fairly uncommon initiative in the schools is now a worldwide phenomenon. The e-pal's network, for example, has over 111,000 linked classrooms involving six million students and teachers in 195 countries. That's a lot of writing. And it's one of dozens of such e-pal organizations and that's just pen pal writing. So even as we meet here, new literacies are expanding almost exponentially and leading the way is communication on next generation mobile phones that do a lot more than let people yak through nano-sized microphones. In fact, cell phones are now so ubiquitous worldwide that global education advocates are seizing on them as a way to promote both written literacy and also numeracy in impoverished areas of the world. The JAKO initiative involves a partnership between UNICEF and Tostan, which means Breakthrough in Walloff, a human rights NGO serving 10 African countries that uses SMS-based innovation to improve the lives of rural poor and those of their children.  There's no power, but they can get the phones charged that way and then people can continue to use them in classrooms and so on. The unprecedented growth of writing across multiple devices in hundreds of emerging genres among hundreds of millions of users worldwide and in rapidly multiplying communities based on occupations, hobbies, extended family, neighborhoods, buying, selling, trading, special interests like canning or woodworking or home vegetable gardens, medical problems, education, politics and politicking is simply astonishing. And as soon as a new system for such uses emerges, another one kind of carves off a particular audience from that new system and provides something more specific. Witness the tremendous growth of LinkedIn.com which is pulling people away from Facebook who are sort of fed up with the trivia, the familial and friend trivia that goes on on Facebook. They want something more professional than that. Meanwhile, aging technologies like email show no signs of diminishing, partly because of increasing access worldwide and if you want mathematical support for this idea, researchers Pelley and Bigelow have calculated a trajectory toward worldwide authorship based on an analysis of publishing trends and readerships starting in the Middle Ages. So there's a lot going on if you wanna equate important books with Twitter, with tweets. So there's a lot going on, but accompanying this massification of writing is a kind of hand ringing on a global scale. Over half of the educators surveyed in a recent study believe that text messaging is harming students' writing and a glance at many blogs and internet forums, I know you can cut the irony with a knife, give voice to the survey numbers as these do. In fact, whole governments are concerned and plenty of social critics have pointed out that there's a certain maybe loss of sophistication in the reduction of language to tiny little screens and limits on characters. It could be said that the entire course of world events would have changed if we had cell phones instead of carrier pigeons and pages riding horseback to deliver sealed scrolls. This was a point made some time ago in the context of PowerPoint, many of you have seen this and what the Gettysburg address might have looked like if there had been another meaning for the word bullet at the time and it doesn't help that the abilities associated with emerging technologies such as texting dexterity, not to be confused with literacy are celebrated alongside a knack for cramming 62 hot dogs down your throat in 10 minutes. Makes you wanna break for lunch, right? Meanwhile, people like Nicholas Carr, the author of The Shallows, what the internet is doing to our brains are having a royalty field day publishing books about the demise of thinking and literacy as we know them. Though I happen to respect Carr as a non-Luddite, he really knows what he's talking about and I kind of at least take an interest in the sort of Darwinist perspective that he has on the recalibration of our brains to adapt to new forms of technology and knowledge. So what does all this mean for college level academic literacy? Well first there's no question that our students today, the ones in college and the ones who are coming to college are writing more than any generation in history if we include all of the vernacular literacies that they're engaged in outside of school. A recent Pew study, for example, revealed that 93% of teens say that they write for their own pleasure. Quote, most notably the vast majority of teens have eagerly embraced written communication with their peers as they share messages on their social network pages in emails and instant messages online and through fast paced thumb choreography on their cell phones. In that same study, almost half of parents believe that their teens write more than they did at that age. As Kathy Ansey points out in a report title Writing in the 21st Century, with digital technology and especially web 2.0, it seems writers are everywhere. On bulletin boards and in chat rooms, in emails, in text messages, on blogs, responding to news reports and indeed reporting the news themselves as eye reporters. Such writing is what Deborah Brandt has called self-sponsored writing, a writing that belongs to the writer, not an institution, with the results that people, students, senior citizens, employees, volunteers, family members, sensible and nonsensible alike, want to compose and do on the page and on the screen and on the network to each other. If we go back a generation or two, young people wrote very little outside of school except those already attracted to bellatristic kinds of things, journal writing, poetry and so on. Ansey suggests that pre-internet, the association of writing with hard work and difficulty with school testing, even with penmanship, pushed all but the most literally inclined students away from self-sponsored writing. And if we go further back, the tools themselves blocked away, messy quill pens and inkwells. I actually used those as a kid in France in the 1950s. We had inkwells and quill, plastic quill pens, followed by messy fountain pens, followed by poorly constructed messy ballpoint pens, followed by clunky typewriters used only by journalists and secretaries. It's probable that the quantity of academic writing hasn't changed a lot in the past few decades either. We don't have good research on this question in higher education and we may be able to get that with FESI, the Faculty Survey of Student Engagement and other kinds of data being gathered. We don't have much now because universities are so different. And I like to think that all the work that we've done on writing in the disciplines, MIT I think serving as a model, has actually made a difference. We do have some pretty reliable numbers from the National Assessment of Educational Progress about writing in US public K through 12 education. And the results are not very heartening. Among high school seniors in 2007, for example, between 70 and 90% wrote common school genres such as reports, summaries, logs and essays, somewhere between never on the dismal end and once a month on the okay, but we'll never get anywhere close to Malcolm Gladwell's 10,000 hour rule for expertise and. Appleby and Langer's work with the NEP data shows that some 40% of 12th grade students report never or hardly ever being asked to write a paper of three pages or more. And we know the problems, problems of high student teacher ratios, lack of funding, lack of training, student resistance and the association of writing with standardized testing, all of those things militate against lots of purposeful, meaning focused writing in the schools. But a lack of purposeful, meaning focused writing is no longer the case in high school and college students' lives outside of school. So if students are writing more outside of school, then we need to consider the question of quantity. It's not going. There it is. Does writing improve in the same way that language scholars describe oral language development? By mere exposure. Does the act of doing writing, regardless of genre, tool, medium, audience, purpose, lead to the development of ability in the same way that doing almost any learned human activity leads to its acquisition and eventual refinement? So this has been one of the mainstays of the writing across the curriculum movement and the assumption that you can't possibly figure it out in 16 weeks, that writing is one of the most highly developmental of human practices, that it kind of spirals up into higher and higher levels of sophistication and disciplinarity and professionalism, and that it's difficult to transfer skill from one writing context to another, a point that I'll come back to shortly. If we put so much into our belief about the quantity of writing in college, then shouldn't it matter that students are writing so much more outside of school? Well, a number of writing scholars think so. Andrea Lunsford and colleague study at Stanford University, which collected every scrap of writing done by a random sample of 189 students over five years, yielding 15,000 pieces of writing, showed that students reported being deeply engaged with writing outside of class. For these students, extracurricular writing is very important, often more important than any of the writing that they're doing for their classes. In fact, all their academic writing accounted for 62% of their total writing. The conversational and public nature of online writing creates a context closer to the ancient Greek rhetoricians' emphasis on finding the right strategies to be persuasive. Lunsford found that students were generally less enthusiastic about their academic writing because it often had no purpose and wasn't instrumental in the world. Good writing has an effect, they said. And although some of the writing was what many years ago, Jen and Emig and others called expressive, that is focusing on the writer's thoughts and feelings about experience in a kind of affective way, often with the self as audience, much of it shifted gears. As students moved along and continued them from very informal to more professional as they wrote on Facebook or for campus groups, off-campus organizations, workplace groups, and most of the students recognized the shifts that are required when writing along this continuum. For example, none of the academic writing of the first year students that they looked at contained even a single case of text speed, LOL or IMHO or any of that in any of the academic writing, whereas the non-academic writing is gonna have a lot of that. Several similar but shorter studies are finding the same thing. Jeff Grable and colleagues at Michigan State had a group of students record everything they did over a two-week period that is blogging, texting, gaming, academic writing, noting the time, genre, audience, location, and purpose. What was interesting to us, he says, is how small a percentage of the total writing the school writing was. In the Diaries and Follow-up Interviews, students often describe their social, out-of-class writing as more persistent and meaningful to them than their in-class work. The writing also had specific goals, such as keeping a group organized or doing something political. And the authors hypothesized that it's what might explain why the students were so engaged. This brings up this issue of engagement and interest again. Of course, the amount of self-sponsored writing is also a function of how much academic writing students are doing. At the University of Denver, for example, Doug Hesse's four-year longitudinal study involving 56 students showed students doing a whole lot of academic writing and somewhat less self-sponsored writing in comparison to these other studies, perhaps in proportion. But not everyone is convinced that more, at least alone, is better. Otherwise, students' writing abilities would flow effortlessly from their Facebook posts and favorite forms into their causal analyses of the Mexican Revolution in Latin American History 300. Or their report on gel formation of peptides produced by extensive enzymatic hydrolysis of beta-lactoglobulin in food biology. Mark Bauerlein, a professor at Emory, points out that N-A-E-P literacy scores have been flat for decades. Why is it, he asks, that with young people reading and writing more words than ever before in human history, we find no gains in reading and writing scores? Well, here we hit the most important barrier to the more is better assumption. And I really am a firm believer of that more is better. And I think, as Bob also showed in the course that he described earlier, you know, it's the foundation of all the principles I have for writing across the curriculum. I believe in, I hope for what I call a saturation model of writing, where everybody's doing some writing in every context where students are learning, rather than here, here, and here. But we need to qualify that and ask more of what and where and better for what and where. And that's the problem of transfer. The genres are too complex. The content is far too sophisticated. The familiarity with academic audiences, especially the disciplines, is far too lacking. Even with all that audience experience outside of school, the lexicons are far too unfamiliar and the sometimes weirdly idiosyncratic expectations of individual faculty are far too unnavigable for students to produce stunning papers. And the problem is that regardless of what experiences they've had, we know from considerable research that writers have a hard time transferring knowledge from one discursive domain to a new unfamiliar one without coaching models, practice, and time to be steeped in the context and figured out how it works. And that's because the further the distance between the two contexts and its ways of mediating knowledge with writing, the greater the challenge for transfer and the greater the need for conscious strategies and problem solving and help. I've begun to think that like the famous Sapir-Warff hypothesis about the relationship of linguistic structure or the perception of the world, there's a strong and weak negative transfer hypothesis. The strong version proposes a mainly social rather than cognitive and universalist view of writing that students can't learn much that's useful until they've been, they're situated in a particular context and a community. As Julie Furch puts it, socially oriented scholars believe that writing practices are deeply embedded in and heavily influenced by the communities where writing occurs. Those communities have their own local conventions, initiation procedures and specialized ways of knowing. The weaker view assumes that some degree of prior learning informs and shapes what students do in subsequent unfamiliar contexts, but that higher level elements that define socially constructed characteristics of genre are not accessible to novice writers in those situations. They have to be learned sometimes painstakingly and through trial and error in a highly situated way. The strong version of the transfer hypothesis predicts that little of students' vernacular literacies will be of use as they tackle challenging academic writing projects in college. So from that perspective, it's convenient to create barriers between the vernacular and the academic. What we do here isn't what you do there. Have fun on your own, but leave it at the door. The weak version suggests that there may be certain patterns of thinking mediated through writing that students might carry with them as they shuttle between literate contexts. Enough experience being forced to support claims about a favorite sport team or pop singer online might actually create some kind of schemas in semantic memory of use in supporting claims about say what would happen environmentally if the B population were decimated. From this perspective, exploiting opportunities to make connections between academic and vernacular literacies starts to make sense. There isn't time to go into transfer in detail. It's a very, as you all know, it's a very hot area of research and scholarship in writing studies right now. In fact, there's a number of you here involved in the Elon University's transfer project, a three-year project to bring 25 or 30 scholars together to work on scholarship on transfer that I've been involved in. Instead, let me briefly share some examples that might show up or show us what vernacular kinds of writing might have in common with academic writing and how we might exploit opportunities to help students transfer discourse knowledge across domains. And I'm gonna start again with younger kids. I didn't cherry pick these. These are pretty much, you find this kind of stuff all over the internet and you've seen it. So these are just random examples that I just found and chose. The first excerpts are from the National Geographic for Kids site. It's really a wonderful repository of information about culture, geography, environment and travel. And kids can post information about where they live or where they're visiting or trips they've gone on and other kids can go on to the forums and respond. What their lives and cultures are like and so forth. So Lewis in London posts an entry about his school. My school is a French school in the middle of London which is a bit strange but loads of schools are like that in London. We do not wear uniforms because in France they do not wear uniforms. There's a Spanish school which we did exchange with this year. There's also an Italian school in South London. My school is in South Kensington near the Science Museum and Natural History Museum where we do visits all the time, et cetera. Zoo Splash then writes a quick rejoinder. Hi, whoa, you are so lucky. We have to wear our uniforms in my school. Tiger Socks picks up on the language issue. I live in Wales and I go to a school where we speak Welsh nearly all the time but I'm fluent in English. My best friend goes to London every weekend because his mum lives there. Then Huru Q writes a longer response. Yo yo people, I'm 11 this year, primary five here in Singapore. Down here only international schools like Stanford America and Australian International and Chatsworth schools do not wear uniforms. Every other school in Singapore has a uniform from primary to junior college. Our uniform is a navy blue pinafore, white blouse, school socks and white canvas shoes on most days and on the days we have PE, we have to wear a school shirt, navy blue shorts and pinafore again. School starts at 7.25 and ends at six. For school government people like me, we have four major holidays, et cetera. And then ends by saying Sian Hoar. So what's going on here? This is not part of a school assignment. First, the kids are learning through mere exposure, I would suggest, all sorts of strategies concerning the relational aspects of writing, how to connect with others through written discourse. They're also sharing information about different cultures, testing and interpreting different ways of understanding their social and cultural worlds and getting just sheer unadulterated information about how stuff works in different countries and cultures alongside contrasting ideologies about the use of language in schooling and requirements for comportment and getting exposed actually to variations in the varieties of world English as you see in the little snippets of Singlish. Big controversy in Singapore is standardization or Singlish with a lot of members of the population saying this is our version of English and we want to keep it. The next example comes from two 15 year olds writing about their favorite football team on a forum called purplepride.com about the Minnesota Vikings. Skull Vikings starts by making a case for the acquisition of Brett Favre, this is a couple of years ago, from a terrible mistake, I guess, in the long run, from the Vikings' greatest all-time foes, the Green Bay Packers. As it looks now, we could be in some sort of running for Brett Favre. Unless you have been living under a rock for the last few weeks, you know what has been going on in this Favre saga. So to the point, the Vikings are better, way better off without Brett Favre, here's why. He won't help the young quarterbacks. Remember when the pack drafted, et cetera. So there's an explanation of point one. Point two, he's too much money. You want to pay him $24 million, et cetera. More explanation. Point three, he won't fit in with childrens, the coach at the time, no longer. I don't see him blending in well with childrens, childrens likes to have control over his team, et cetera, Brett won't. And then so forth. We would have a media frenzy. He cost the pack the big game last year. He won't help out the quarterbacks and so on. If you have any other reasons why you feel this is bad, move definitely post them here. An invitation for response. So out of the many, many interactive responses, and I happen to know that the person who responded was about the same age as the kid who wrote. We see a counterpoint for each of the arguments. One, won't help out the young quarterbacks. He's been teaching the young quarterbacks, et cetera. Too much money. We have the cap room, using a little bit of the jargon of football, right? Won't fit in with childrens. What even makes you think that? Has he ever not worked out well with a coach? Media frenzy. Two words, who cares? I live in Dallas and Tio and Romo get a ton of press. Cost them the big game. He's the biggest reason they got to the championship game last year. I think there's a ton of good reasons to bring him in. Hall of Fame quarterback, he's better and et cetera, et cetera. So what's going on here? Clearly both writers are learning strategies for framing arguments and persuading audiences and having studied this forum for a little bit. I can tell you that its community is ruthless about wanting evidence for assertions. Way more than I would say most academics are. You know, you get slammed if you don't have enough evidence for your assertions. Now these are kids, these are young and there's a lot of other people on there who are older. So it's a mixed age form, which is also very interesting. You've got people at different levels of cognitive and intellectual development who are responding with these kids in the mix. So we see lots of things going on here that's done in a completely self-sponsored way without any schooling involved. The third example comes from a site called Prison Talk where family members of prisoners and in some cases prisoners themselves can discuss issues related to their concerns. And here we see just a simple exchange of information. Nothing particularly striking about higher level literacies here, but I wanted to share it because it reminds us of how important engagement and purpose are in developing literacy. Again, a point that Bob made earlier about interest. If you really, really want information, you'll devote a ton of intellectual resources to framing a question, interpreting a response, figuring out what else to say. Here's the response, adjusting your point. So there's no way that learning cannot be happening here. The final example is from responses to YouTube uploads, which, if you've ever looked at these, they're rife with intellectual garbage, name calling. And so these comments came after a YouTube video and report about a 40 ton whale that breached and landed on the deck of a sailboat off the coast of South Africa, much to the surprise of the couple on board. 485 comments were posted after this video appeared. Cowie wrote, I hope the whale is okay and you aren't supposed to get too close to the whales for their own good. You're supposed to leave them alone and stay a safe distance. So yes, it is kind of harassing a whale, to which Placen replied, eff the whale. It damaged a boat worth far more than it. Hope it didn't cost the people too much and I hope someone shot the effing whale for being a menace. Retolites jumps in to the ring with, I'm very sure the whale only wanted to play. Whales are very friendly creatures and they usually do dive that way for fun. This whale probably just lost control of where it was going to dive. I hope this whale is okay, to which Motor Attic said, that's very true. I've also read about a peduncle throw, which is an aggressive movement between competing whales and a defensive movement against threats, like a boat that's too close, for instance. As for everyone who thinks harassing the whale is a ridiculous statement, what do you think is more natural? A whale breaking the surface of the water in an act it has done instinctively, forever or a yacht? So even here, amidst a lot of other useless posts, and there's a lot, this, you have to, you can actually ask the forum to look by thread so it tries to pull people out because there's so much stuff in between that you can get lost and people are responding to each other. So there's a lot of other very useless posts. There's people who get into an argument after this YouTube environmental argument about the worth of whales, the worth of humans, what are we doing to the environment? And some of the anti-environmentalists are just particularly nasty and do a lot of name calling, and then it sets up other people to name call back and it kind of descends into silliness. But we can see, even amidst a lot of these useless posts, we can see signs of a kind of engagement through writing that shares knowledge and perspectives.  But consider what does come through, information about whales and ideological tensions between animal protectors and those who don't care, emotional but interesting perspectives on the importance of humankind. And we even, in this example, we see occasional lessons on text itself as this rather vitriolic exchange shows about ellipses. Cowie says, LOL, trying to go out of your way to upset someone in between way too many periods and laughable grammar skills on YouTube. Yet another example of why humans are the most useless and unintelligent species. Animals, this is a person who's also arguing really in favor of the whale. Animals we hear long before are disgusting species. If we didn't have so many stupid weapons, we would still be at the bottom of the food chain where humans are supposed to be. Placen says, they aren't periods, dipshit, they're called ellipses. They separate thoughts, of which I'm sure you aren't too burdened. Your logic is what's laughable. If we didn't have so many stupid weapons, we would still be at the bottom of the food chain where humans are supposed to be. Well genius, it's not the weapons that vaulted us to the top of the food chain, it's the intelligence behind their creation that put us there, as other animals have tools to survive, so do we. So let me wrap up by suggesting that if we believe that experience in writing of whatever kind lays some sort of foundation or schemas for further writing, then we need to pay attention to and bring in students' non-academic writing experiences into the academy. In foundational experiences, that will mean helping students to make what is, I assume, pretty tacit knowledge. I don't think those 15 year olds are thinking, I'm gonna use a particular logical device here to slam my opponent. They're not actually in tune with the, they're not able to make explicit the things that we make explicit in teaching. Any more than kids know anything about language and our wonderful language users, right? They can't tell you how they construct a sentence. Any more than probably the vast majority of human beings can tell you how they're constructing sentences. We just do it. Oh, noun phrase, adjectival modifier. We just don't think that way, so. So this is a question about making tacit knowledge conscious so they can develop higher level strategies for writing and other communication in all settings. In the disciplines, it will mean bridging the gaps between the various forms of communication both in the academy and elsewhere. And it will also mean admitting that many of the things that students do in their vernacular literacies have parallels in professional discourse. Note Suzanne's description earlier of the multimedia publications now, right? That are happening in the sciences and elsewhere. Such as forums, blogs, listservs and other academic and professional tools for creating and sharing knowledge. So as Lunsford points out, the changes that we're experiencing in communication technologies are altering the very grounds of literacy as the definition in nature and scope of writing shift away from the consumption of discourse to its production across a wide range of genre and media, away from individual authors and to participatory and collaborative partners in production and away from a single static standard of correctness and toward a situated understanding of audience and context and purpose for writing. And it seems to me that it's precisely why symposiums like this one are so important for us to meet the challenges of these changes with curiosity and reflection and tweets and blog posts and academic papers. Thank you. Hi, I can't believe it. We're actually on schedule. Let's save the questions when we come back. Okay, what we're gonna be doing now are two things. Lunch, and those of you who have purchased lunch, it will be distributed in lobby 13, which is through a passageway down by where you registered and there are tables set up to eat as well. And then after that, we're gonna have breakout groups and you should have your assignments for your breakout groups for an hour. We will be back here at 2.15 for a panel of discussions. One of the main functions of the breakout groups is to generate questions for the discussion panels as well as to generate questions for the speakers. After the discussion panel, keynote speakers will be back up here together and there'll be a question period and also just discussion. Thank you very much.


Hi, my name is Russell Keith Piggy. I'm here today to show you how you can publish your Python code as an app using briefcase. Little about me, I am from Wajuk Nungabuja, otherwise known as Perth Western Australia. I am a principal engineer in the open source group at Anaconda. They pay for me to attend conferences like this one to talk to people like you. So I'd like to thank them for that support. They also support the Python open source ecosystem more broadly by providing direct financial support to organisations like NumFocus and by employing developers to work full-time on open source projects, projects like Jupyter and Numper. And the open source project that I founded, Beware. For those who haven't come across it before, Beware is not a single product or library or tool. It is a collection of open source tools and libraries for creating native user interfaces in Python, for desktop but also for iOS, for Android and single-page web apps. Each tool in the Beware suite solves one specific part of the overall problem of writing a GUI app in Python and distributing that app to other people on various platforms. Anaconda supports Beware to ensure that Python remains a viable programming language on the platforms that people are increasingly using as part of their day-to-day computing life, phones, tablets and so on. However, it is important to note that Beware is not an Anaconda product or anything like that. It is fully open sourced with independent governance and funding. I just happen to be paid by Anaconda to work on it full-time. Today we are going to look at one of those tools in-depth, Briefcase. Briefcase is a tool for packaging Python applications. It takes your Python code, wraps it up as a standalone unit that you can give to an end user with no Python experience and they can then run or install and run that app on their platform of choice without ever knowing that they are running Python code. Although it uses a pyproject.toml file for configuration, it is not a competitor for setup tools or hatch or flit or poetry for building library wheels. It is not for deploying Django or Flask websites, it is for packaging applications like the ones you would install from an app store or find on your launch pad or start menu. Think things like MS Word, Firefox or Photoshop. It produces an MSI installer on Windows, DMG or raw app bundles for macOS.deb.rpm or package ZST files for app images or flat packs on Linux. It produces iOS and Android projects that can be uploaded directly to the Apple app store or Google Play stores respectively and it produces a zip file you can upload to a static web post for a single page web app. It is also highly extensible so if you wanted to add a snap back end for Linux you could or if you wanted to support an entirely new platform like a set top box or a watch you could do that as well. Briefcase is just as I said one part of the overall Beware suite of tools. While Briefcase is, it does integrate very well with those other tools, it doesn't require the use of those tools. Beware has a GUI toolkit called Toga but you can wrap your Pi side app or Pi game game with Briefcase. Briefcase also isn't a very good match for command line tools at least not yet on every platform. The primary focus of Briefcase at the moment is packaging GUI applications. It can be used for command line apps on Linux. It could potentially be adapted to do that on Windows and Macros but it can't right now. I'd be interested in seeing that use case supported so and I think I know how it can be done as well so if you want to know more come talk to me afterwards or during the questions. The approach used by Briefcase is essentially the dumbest thing that could possibly work for the problem of app distribution. A Briefcase application is a full copy of all your Python code, a full copy of all your code's dependencies and a full copy of a Python interpreter and a stub binary that can be used to start your application. All bundled up in a way that makes sense for the platform that you are supporting. I say it includes an independent Python interpreter, it's probably more accurate to say it ensures a Python interpreter is available. On most platforms that means shipping one but on Linux it can use system packages in some distribution modes. The stub binary is needed so that your application presents as my app.exe rather than Python.exe and to control the runtime Python environment essentially to make sure it doesn't pick up any stray imports from other Python parts but the stub binary is effectively doing exactly the same thing that Python.exe does, it just has all the configuration options filed off and that's pretty much it. Briefcase is mostly a templating tool combined with wrappers around PIP to install your Python dependencies, wrappers around whatever native platform tools are needed to build a DMG or an MSI or whatever else and then sign applications for distribution. Now Briefcase is not the only app packaging tool that exists for Python so why should you use Briefcase and not one of the other options? Well, first off, it doesn't try to be clever. Some alternatives to Briefcase like PyOxidizer or PyInstaller and some modes of operation can involve getting a working app with making an executable and to support the aim of making an executable they play tricks with your code. They bundle it up into a zip archive that's been embedded into the data block of an executable that's unpacked into memory at runtime and that approach can work and when it does work it's great if only because it gives you a single executable that is distributable but it doesn't always work and for a number of reasons, one of which is that a lot of Python code is designed to be run by passing an interpreter over directories of files on disk and that's how Briefcase runs Python and interpreter running over a directory of source code. The only thing Briefcase does is automate the process of getting that working interpreter to an end user in a way that doesn't require the end user knowing anything about Python. Briefcase also cross-platform which means you also have a single configuration file that produces installers for Mac OS, Windows, Linux, iOS, Android and web which means you don't have duplicated configurations for distributing your app, removing a potential source of error. So how do you use Briefcase? Well, the easiest approach is to start a new project from scratch, create a virtual environment, install Briefcase, pip install Briefcase. Briefcase includes a wizard to start a new project. You say Briefcase new, you'll be presented with a list of questions and some explanatory text. You'll be prompted for a formal name, that's the name you show to humans and an app name, sort of a Pythonised version of the name, something you would pip install. You'll be asked for a bundle, let's use for namespacing to separate my hello world from your hello world. It's a common format used by app stores. It's usually a reversed ordering of a domain name that you know. So that bundle is then combined with the app name to make a full bundle ID for your app, so org.beware.hello world. You'll be asked for a project name, a Briefcase project can include multiple distributed apps, you'll be asked for a one line description of your project, author's name and email, that's then used in help text and copyright labels, a URL for your project, a license and lastly a GUI framework. Briefcase provides a template for Toga, which is BeWare's own GUI framework, but there are also templates for PySide, Pursued by Bear, Pygame, or you can select an empty project with no GUI toolkit at all and drop whatever toolkit you want in there. When you complete the wizard, Briefcase will give you instructions how to run your project. And if you look in the hello world folder that's been generated, you'll find a complete stub project including enough code to start an app, application icons in a variety of formats and project metadata. You will get the same files regardless of what GUI format you pick, the only difference will be the contents of app.py, main.py and some of the values in pyproject.toml on the read me and the license file. Pyproject.toml is the configuration file for the project, contents of this file will match the answers that you gave when you set up the wizard. All of the briefcase options are defined in tool.briefcase sections of the and various subsections of that file. The top level project and author identification is in tool.briefcase. And although the template that Briefcase generates with the wizard doesn't include it, Briefcase will also honor all the equivalent PEP 621 metadata keys with the values in tool.briefcase overriding the PEP 621 keys if they've been provided. Individual apps then have their own sections in the file. So this configuration section here tool.briefcase.app.hello world is the configuration for the hello world app inside this project. That's the hello world there is the app name, the formal name of hello world is done just underneath it and then we've got other descriptions there as well. At runtime the configuration for the hello world app is composed out of your project settings overridden by the app settings. So although there isn't an author name listed here in app config, it would inherit one from the project level configuration from the previous slide. If you wanted to have a different author name for this app in your project, you could do so by just adding an author name in the app's configuration block. You'll also notice the icon setting doesn't include a file format extension. That's because Briefcase uses the provided value as a base name and appends the format depending on the platform. So .ico for windows, .png for Linux and so on. On some platforms you actually will need to provide multiple icons in multiple formats, multiple resolutions. Those sizes will be appended to that base name to produce a full name. Now I say that app settings override project settings. There are four exceptions to this behavior. Sources requires test sources and test requires. Sources describes the list of directories of source code that you want to include in your app. So here we're saying everything in the source hello world directory is going to be part of my application. Any code or resources in that folder and its subfolders will be copied into your application bundle. It's a list, so if you specify multiple sources they will all be copied in. The only requirement is that one of your source directories needs to match the name of your app. So hello world in this case. Requires defines the Python requirements for your app. Again, as a list using the same format that you'd used to as an argument to pip install. So a bare package name, a package with a version specifier, a git repository, a path to a local file that contains an installable package, they're all valid options there. Test sources and test requires are essentially the same, but they define code that will only be included when you're running the app in testing mode. These four settings are cumulative settings. So if you specify a sources definition at the project level, any app level sources will be appended to the list that are defined at the project level. So that's you define common requirements at a top level and then application specific requirements as you go. Why does this matter? Well, you can also specify options that are platform specific by adding a configuration section for that platform. The generated PyProject Toml will include a section for all of the supported platforms, Mac OS, Linux, Windows, iOS, Android and web. So what we've got here is the specification for Mac OS. These options will only apply to the Mac OS builds of this app. Sources requires test sources and test requires are cumulative. So any deployment options here will install all the common requirements like NumPy from the previous slide, but will also include Togo Cocoa and Standard NS Log. A Windows deployment will also have NumPy, but won't have Togo Cocoa and Standard NS Log. It'll have Togo WinForms instead. All other settings override app level and project level values. So if you wanted a Mac OS author name, you could drop an author name in there if you wanted. For most platforms, you only need to platform configuration. However, the Linux configuration needs to go a little bit deeper. This is because Briefcase supports multiple packaging formats. There is a Linux section for common settings to all Linux deployments and all Linux packaging, but then there are format specific sections. By default, Briefcase will generate a system package for the Linux distribution you are currently on. So a Debian or a Deb or an RPM. There's a System.Debian and a System.Rail section. You could also add System.Abuntu or System.Fedora sections if you need to define, if you need to generate a package for those platforms. These let you define system specific requirements. Usually system packages that need to exist on your computer to be able to build or use the package. Briefcase also supports app image and flat pack output formats. They have their own configuration options. Now, this stubpriproject.toml file was generated for you by Briefcase Nu, but you don't have to use that wizard. If you've got an existing project, you can roll your own Briefcase configuration into a pyproject.toml by hand. You've just got to put all the keys you need in. The only requirement that Briefcase puts on your code base is that if you are deploying an application called foobar, then you must have a foobar executable module in your code that is your app's entry point. A done domain file in a foobar folder. That's it. What that entry point does is entirely up to you. As long as it's included in your sources definition, Briefcase will try to run it. Alright, so however you've created it, you've now got your Briefcase configuration file. How do we use it? Well, the first thing you want to do is just see if your app runs. Briefcase includes a developer mode which lets you rapidly iterate on your app and its configuration.  The first time you do this, it will actually install all your declared dependencies as well. So everything in your requires section will get installed into your local virtual environment. Now, keep in mind the design motivation for Briefcase, Briefcase, the dumbest thing that can possibly work. Briefcase dev is really not much more than shorthand for PIP install for the list of requirements that you've specified, followed by Python minus M hello world with a couple of debug flags turned on. On subsequent runs, the dependency step won't be executed by default. Briefcase will only start the project. It's just to make the startup loop a little bit faster. If you do add or modify dependency, you need to add a dash r flag when you run Briefcase dev. That will force an update of the dependencies as well. And if all you've got is the content generated by the wizard, at this point what you'll get is a working app. It will be an empty window, but it will be a working application. You can now iterate on the code in your app, add features, fix bugs, whatever you need to do, stop the app, add some code, rerun Briefcase dev, the updated app will run. Awesome, we've got ourselves a fast development loop for our application. Eventually, the time will come when we're going to be ready to package our app for distribution. First step, we need to create our app. To do this, Briefcase create.  First, it will look for the platform you are currently on and get an application template for that platform. So I'm running on Mac OS, it will use the Mac OS app template. Secondly, it will obtain a support package. A support package is a version of Python that can be embedded into your app. For Windows, we use the officially supported Python embedded package for every other platform. Beware, sorry, except for Linux, Beware maintains a support package. We use another project's package version on Linux. Whatever your platform, Briefcase will download the support package, unpack it into the application template that was just created. Then Briefcase installs your application code, anything declared in your sources section of your project. It then downloads and installs your app's requirements but it doesn't install them into your local environment. It's installing them into the application template. Because you're building an app for distribution, you can't rely on anything that's in your local environment. It needs to be in the application. Then Briefcase installs any application resources, things like icons. It purges any content that isn't needed. So on Mac OS, for example, we include an XC framework that you don't need at runtime. And then it's done. You've got a complete application template. Your project directory will now have a build folder that contains a platform-specific template for your app. The next step, build your app. Shocking, I know, but it's Briefcase build. What happens in this step varies from platform to platform. On Mac OS, it needs to sign the application bundle so that it can run on device. On Windows, it needs to write some app metadata. On Linux, it needs to compile a stub app. And at this point, there will be a subfolder of the build folder that contains an application along with any other files included as part of the build process. So in this case, again, it's a Mac OS app. If you were to click on that icon, the application would start. Or you can keep a console based and use Briefcase. Run your app with Briefcase Run. And what you should get is a running application. It will be very similar to what you see with Briefcase Dev with a couple of distinct differences. The app will present to the operating system with your formal name. So you'll see Hello World up in the top corner of the screen there rather than saying Python. We'll also have an application icon in the toolbar down the bottom. Little Hello World, it'll be there. Depending on your platform, there may be some other differences as well. The last step is to package your app with Briefcase Package. This does any final packaging that has to be done before distribution, so creating an installer, doing final code signing and so on. Once this command completes, the disk folder in your project will contain an artifact that can be handed to someone for distribution. So a DMG, an MSI, an RPM, a dev, whatever is appropriate for the platform. Some caveats about packaging. At present, we only do automated signing on Mac OS and Windows. On Mac OS, we do full signing and notarization. On Windows, we sign the XE and the MSI file. We've got documentation on how to manage signing for mobile platforms, but the process isn't currently automated. That is something we want to address. Again, if you want to contribute, this is going to be a place you could help. Signing Linux packages is a complete unknown. Patches welcome. The framework is all in place. What we really just need is the specifics of how do you sign an RPM file? How do you specify a signature on RPM file? If you are on Linux and you want to package for another distribution, say to produce a deb file while you're running on Fedora, you can using Docker. Briefcase will manage the entire process of using Docker. You just need to make sure that Docker is installed. So if it is, you can pass in dash dash target with a Docker base image and Briefcase will package an app for that platform. If you're on Mac OS, you can also use that trick to build packages for Linux using Docker. Briefcase package Linux with a dash dash target, it will do exactly the same Docker trick. Spawn up a Docker container and build a Fedora package or a Debian package, whatever. Unfortunately, this doesn't currently work on native Windows. It will under WSL. You also can't build a Mac OS package on Windows or a Windows package on Linux because the tooling to do that is platform specific. CI platforms are your friend here. Okay. So we've packaged our app, we've distributed it to you, distributed it to our users and then you start working on version two. Do you need to go through this whole development process again? Well, you can or you can say Briefcase update. By default, this will reinstall the code for your app if you want to update your requirements as well. You can specify minus R if you want to update all the application resources like icons, you can specify dash dash update resources. Some other features of Briefcase that are worthy of note along the way I've basically been saying Briefcase command as the shorthand in every instance that's actually is a shorthand for Briefcase command platform format. So Briefcase will identify what platform it is running on and pick a default format for that platform. So most platforms have alternative format so you can target an Xcode project rather than a Mac OS app or a Visual Studio project rather than a Windows app or an Athymedial flat pack on Linux. Briefcase create Linux flat pack will create a Linux flat pack. Briefcase also implies earlier steps if they're needed. If you have a fresh project run straight out of Briefcase new and you invoke Briefcase run Briefcase will detect there isn't a template yet so I'd better create it. I haven't built it yet so I'd better build it and then it will run it. Briefcase run also allows for a dash U option which will update the application before execution so your development cycle could just be running Briefcase run dash U over and over and over again. Briefcase will also open your project if it's a simple project like a Mac OS app that's really just telling the file manager to open a folder if it's an IDE batch project it will open the IDE on the project that is generated if it's a Docker build it'll open a shell session on the Docker container that was used to build the app. All right so that's desktop deployment what about deploying to mobile platforms well the steps are essentially the same just add iOS or Android to all the commands Briefcase create iOS Briefcase build iOS and so on similarly for Android Briefcase run Android iOS builds only work on Mac OS but that's because of the underlying tooling requirements Xcode is only available on Mac OS so we're limited there Android builds though will work on Mac OS Linux or Windows when you run Briefcase run iOS Briefcase will ask where do you want to run this code it will look for simulators that are on your system and provide a list to choose from and if you want to shortcut that question you can specify minus D give it a device ID or a device description like an iPhone 14 running iOS 16.4 if there's any ambiguity because you've got multiple iPhone 14 simulators you'll be asked to resolve the discrepancy on Android you'll be asked to walk through the process of creating a new emulator image if you haven't previously created one but once you've picked a device you'll see something like that iOS can currently on the target simulators Briefcase will manage the process of starting the simulator launching the app in the simulator tailing the logs so that you can see the app run you can deploy to physical devices but you need to use Briefcase open to open the Xcode project and then run it through Xcode because there's a bunch of signing things that need to happen that we haven't yet automated on Android you can target emulators or attached devices you need to do a little bit of a dance with the physical device to put it into developer mode and press the settings button seven times in a row and a bunch of weird stuff Briefcase will try to glide you through that process and then point you at docs if it doesn't seem to be working One last deployment target the web if you add web to the end of the commands we've run so far what you'll get is a Briefcase will start a local web server open a browser and you'll see your app rendered as a single page web app all the app logic is executing in the browser so it's not server side it's using PyScript to embed a full python interpreter in your browser and your app's code is running in the browser so Toga B-Wears GUI toolkit includes a web backend this is the Toga backend that needs the most work if you have web skills and you want a way to contribute and you're here for the sprints this is absolutely a place you could help so far we have been writing code using Briefcase dev to check the code works as we expect and Briefcase to run and execute that app as a package bundle if you're building an app for real you're probably going to need to test it your app will have business logic if you want to really want to run the tests of that logic in the environment that is as close to production as possible so if you're developing a mobile app you kind of want to run those tests on a phone so you can verify everything's going to run as you expect so Briefcase supports running in test mode both developed mode and packaged apps can be run in test mode so you can run a test suite on a mobile device simulator the stub app that's generated by Briefcase dev contains a PyTest test suite with a dummy test you just need to extend that test to test suite to validate whatever your app's code is doing the test command returns success or failure at the shell level so you can integrate that into CI processes or part of a PR acceptance release process okay so some common questions and problems the most single most common question in the Briefcase support channel my app runs fine under dev mode but doesn't under run this is because your dev app runs in your local virtual environment run is a standalone environment if you have manually pip installed something locally in your virtual environment it will not be available to your packaged app you need to add an explicit declaration of that requirement in the requires list of your app and then you need to call update minus R to make sure it's installed into your packaged app another common problem Briefcase is only as good as its underlying tools for example Android emulation and Docker both have very specific hardware requirements if your laptop doesn't support those requirements you're not going to be able to run an Android project or build with Docker Briefcase does what it can to identify some of those common modes of failure but it's not perfect sometimes you're going to get back an obscure error coming from Docker and you're just going to have to find out what's causing Docker to do that and it's likely something like hacksome integration which is a CPU hardware level thing Briefcase also can't magically invent platform support that doesn't exist Toga runs on all the platforms that Briefcase supports but it's currently the only toolkit that does you can't use Briefcase to produce an iOS game with Pygame because Pygame doesn't support iOS Qt apparently works with iOS and Android but Pyside the Qt bindings doesn't Kivi is an interesting case here it should in theory be possible to deploy a Kivi app with Briefcase but mobile deployment is a bit of a complicated beast and so that doesn't work out of the box right now we would very much like to support Kivi so if you know anything about Kivi and you are interested in Kivi support come have a chat because absolutely want to be able to do that What about third-party code? Well if the package you're looking for is pure Python and it's on PyPI you can just use it put it in your requires list and be done with it the only place that will fall down is if you've got sys.platform equals logic in it in which case you might need to submit a patch to actually get that code to support iOS or Android Anything with binary modules that's a little bit more complicated on desktop binary wheels just work they're pip installed they're distributed without any difficulty on mobile binary wheels just work too but most packages don't publish binary wheels for iOS and Android in fact Beware is currently the only group we're aware of that's publishing by or even building binary wheels for iOS and Android we maintain independent pip compatible repositories where those but wheels are stored if the package you need is on that supported list you're fine if it isn't building them is complicated this is one of the big items on out to do list for the coming year in the meantime NumPy, Pandas, Pillow, old versions of cryptography and about 40 other popular packages have binary wheels unfortunately, PsiPy and OpenCV are two common packages that don't run on iOS at least for now we still need to find we need to find a Fortran compiler that will work for iOS Briefcase isn't a feature complete tool by any stretch it works well but there are a lot of places where it could be enhanced or improved I've already flagged some of the obvious performance or potential improvements supporting new platforms like setup boxes and smartwatches new packaging formats like Snap on Linux adding those features actually isn't that much work it requires a little bit of expertise or research on how to drive the packaging tools on those platforms but if it can be done as an external plug-in registering against entry points that Briefcase provides I'd like to be able to provide an answer for command line apps as I said before I think I know how it can be done just need to do the work permissions are also a big item on our wish list this is the most significant on mobile where you need to ask for specific permissions to access the camera or access geolocation services these permissions are becoming increasingly common on desktop as well I expect this will be coming sooner rather than later just purely because you've kind of got to have them we'd also like to get iOS and mobile to tier 3 support in CPython Core and eventually have CPython distribute the support packages that Beware is currently maintaining part of this effort will be making the cross-platform builds with a pet 517 interface something that's officially supported we're going to be starting work on this sort of in a month or two lastly at publication Briefcase currently stops the process of packaging your app however app stores all have APIs to support automated publications so potentially Briefcase could manage that process too and that's Briefcase if you do nothing else I recommend going through the Beware tutorial docs.beware.org everything I've spoken about today is part of Briefcase there are plenty of configuration options that I haven't gone through if you want to know more Briefcase's documentation is very thorough if you haven't got I haven't got any detail on Toga Toga's docs aren't as complete as Briefcase but they're getting a lot better and the latest build on Read the Docs is getting reasonably feature complete but there is also a separate Toga tutorial plus a lot of sample code and projects in the Toga GitHub repo if you like what you've seen here and you'd like to support this work on Briefcase and the Beware project you can join the project as a financial member you can also back me on GitHub sponsors the income we raise is used to cover stickers and hosting and things like that like I said earlier I am paid to work by an account to work on Beware but the project itself is independently managed and funded so that financial support is important we've also got a discord plus discussion forums ticket trackers for all the projects details on Beware.org or if working kind is more your thing we're always looking for new contributors we have a long list of features we'd like to add we have challenge coins for people who contribute I will be here for the full sprints we've got a list of issues for first-time contributors and there's still plenty of low-hanging fruits even if you're inexperienced as a Python developer Thank you so much Russell there are some questions that we have here up front this project seems to do everything is there anything that's out of scope or is it just like you want to do everything and be everything no okay so space lasers to destroy the moon no not going to do that the but like if I have space lasers you can bundle it for iOS well yeah so the the key thing is that it looks like it does a lot it's actually not most of the stuff that's actually doing is other tools all we've done is put a wrap around the outside of it so that I don't have to teach a Python programmer who's just done you know a Django Girls tutorial or something like that how to drive Xcode configuration options to get a big get code on their phone under the hood you can actually like you put it put a briefcase into verbose mode turn on dash dash vv it will show you the command line stuff that it's running and it's just command line execution of a bunch of system tools with all of that detail to kind of abstract it away and made common into a configuration file format rather than spewing you know all the all the stuff that an Xcode build will throw at you or Android build or anything else so it's it's trying to make the process of getting code onto actual devices easy by wrapping the tools that already exist in a nicer interface thank you we have time for one more question Emma please in the back hello so I will try to keep this short it's so you talk about different distribution windows Linux you didn't talk about cross processor architecture like ARM versus i86 and as a sub question I run termics on Android so could I take some of the packages from beware that don't combine natively and use them in termics that would be an interesting for the android would be an interesting one probably not I would need to look a little bit deeper the in terms of CPU architecture support for desktop platforms it's basically x86 on all of those platforms we do both like a universal two fat builds for M1 and x86 on macOS on device we are looking to target a native android application it builds i386 x86 64 ARM 32 ARM 32 eABI and ARM 64 what that means for the native packages on Android good question I'm not sure I'd have to look thank you thank you so much Russell