revision control

Collaborative tools for designers − part 6 : the Githosters

The Githosters

Part 6 of this series of posts around my quest for tools that would encourage or facilitate collaboration with and between designers, this time, I went over what I’m calling the Githosters, also known as Github, Gitlab or Bitbucket.

Github is so popular these days it might become a verb one day and for some, there is still confusion between Git and Github. But since its beginning in 2008, coders have embraced it. It’s their social network. And they’ve been followed by a growing population that works also sometimes with coders such as journalists, jurists, typographers, icon designers, cartographers, etc. So we’ve actually come a long way since SourceForge − once the “only” place to get some open source software − and I guess, for the better. Github also helped popularize Git and became a central place to experience “code based” development as a community. With a major web actor such as this one, comes a list of alternatives, such as Bitbucket, pretty much born at the same time (at the beginning using only Mercurial, but later also Git) and more lately, Gitlab, the open source equivalent that you can host on your own servers.

The crowd that has followed the coders is the one that’s the most interesting to me. And I’m guessing the future of these tools depend on it. The winner in the next years will be the one that manages to keep its crowd of developers while providing relevant tools for all the other creators that surround it. And we can see that some of those players have started to understand this.

Github visual diffing

Let’s start with Github, since they are leading the pack. Github offers previews and version comparison for certain files. Which means that you can see how some of your graphic files have evolved through their commit history. They do this for psd, jpg, png, gif, svg and stl files. They also support rendering of pdf (but no diffing). It’s worth noting that Github renders also IPython/Jupyter notebooks, csv tables and geojson map files (the latter with diffing), appealing there to the data scientists and alike.

All of these features are great and can encourage non-coders to use that service. But it’s very limited to viewing a file, just one, and in some cases, compare 2 versions of that file. But the rest of the interface is pretty focused on code only. Coders might know what to do with a file just by seeing its name, but designers like previews and thumbnails. And none of this is available so far, resulting in many clicks to view the content of a folder and finally seeing the file you were looking for. I do understand that this is a tool for coder, but if Github wants to please another crowd, they might have to propose a different interface. I’m guessing they could do this through an desktop client − by improving the one they already propose for example − or by providing a different web interface depending on your role. The issues and comments could also be enhanced to enable some form of “image annotation”.

Bitbucket, from the point of view of a developer, does not seem to be lacking features compared to Github. It boils down maybe to some interface choices, but they overall look the same to me (although I’ve not used Bitbucket extensively, just for this test). Although with graphic file handling, I had the feeling Bitbucket is still buggy or unpolished in the corners. They seem to go in the same direction as Github, but if psd files are supposed to be rendered, all I got was broken/empty previews. The rendering and diffing works for svg, jpg, png and gif. Good. But no pdf rendering and most “binary” file formats spill their content source when viewing commits. I know it’s the default behavior of Git, but this creates pages and pages or gibberish content in the web browser that is totally unnecessary.

Like Github, Bitbucket proposes an in-browser file editor, if you quickly wish to correct a typo somewhere and commit immediately. But why offering this feature on image files? At first, I though: “wow, could I edit my image files right in the browser with Bitbucket?“. Answer is no, you’ll see a series of characters (Base64? or cyphered exif data?) that you’d better not touch if you don’t want to make your files definitely unreadable.

Bitbucket also offers a desktop client, but didn’t take the time to install it as it was looking more like a Soyuz cockpit again and only seemed to focus on coders also.

Gitlab file viewer

Lastly, let’s go over Gitlab CE, perceived as the open source clone of Github, but I guess that’s what most of us expect. Their Community Edition (CE) is a full featured “Github clone” that you can install on your own server. So it’s pretty convenient if you care about secrets or the indieweb. Unfortunately, they support fewer features regarding image handling. You’ll get a preview of most web file formats (jpg, png, gif, but not for svg) and visual diffing for those. But no pdf viewer (yet) or other fancy stuff. Since Gitlab is open source, it means we could drive it in the direction we’d like, or at least we might make propositions or fork it to bring it into a more designer friendly direction. Although the fork is maybe too far fetch as they seem to be very open to new propositions.

Even if these 3 solutions are a little poor relative to what we’ve seen in previous posts about collaborative tools for designers, I’m definitely in favor of a Git based solution than a Dropbox (or similar) solution. What Dropbox misses totally is the collaborative work between designers and developers. And devs will never use Dropbox to version or share their code. While designers, provided with the right interface, could totally switch for Git. In that sense, for those looking for an easy solution to collaborate with developers on Git repos without learning any Git command, I recommend SparkleShare. It’s kind of like Dropbox, but with a Githoster backend. Though you better warn your devs that you’re going to use this, because your Git commits are going to be pretty dull and voiceless. For the rest, it’ll be as simple as saving your files from your preferred graphical application into the right folder. All the rest such as pulling, committing and pushing is handled by the Sparkleshare, running in the background.

That’s it for this part. I know there are some other Githosters out there. I did not want to go over them all, just the most popular ones. But if I missed one that has some great features or that is much more promising for designers, don’t hesitate to drop a line in the comments or contact me.

Collaborative tools for designers − part 5 : Adobe Creative Cloud

Episode 5 already. Damn, so many collaborative tools for designers. Yes. And this post is about the one everybody talks about, but what they are actually referring to is something else: Adobe Creative Cloud. Let me rephrase that. When you tell people you are trying out Adobe’s cloud, they think you are using Photoshop or something. They don’t picture that what you are actually studying is the file hosting and syncing with Adobe’s servers. You know, the thing that works like Dropbox. Well, unless I’ve badly searched in the giant list of Adobe’s applications, the only tool they advertise doing collaboration and versioning, is Adobe Creative Cloud. Yes, the syncing app with the “real” cloud. No, not Photoshop. Your files, on their computer. You get it.

And don’t tell me it’s called Adobe Version Cue. Has anyone ever used this? I tried. A long time ago. And did not manage to make versions of my files with it. So I abandoned. And so did Adobe.

As I flew away from Adobe products since the first Creative Suite versions, I really thought that people were actually using the “cloud” services from Adobe, so I was surprised to hear none of my friends were actually using the 2Go of “free” hosting offered with their subscription. So to complete this review, I asked some friends if they wanted to test it. Sébastien Monnoye, teacher and designer, who also had never pushed files on the Creative Cloud before, answered the call and we started sharing folders together and explore the tool.

One thing for sure, and you guessed it, is that it treats Adobe’s file format very well. The rest, not that much. You can, of course, see a preview of .psd and .ai files in the browser. But you can also break down that preview by turning on and off the individual layers for those files. Neat. With a click of a button you can extract certain elements from a .psd or a vector file and add them to a library of assets. These libraries are accessible right from inside Photoshop or Illustrator. So you could just drag and drop from those into a new design. It really speeds up the reuse of certain elements you might have made in your previous projects. (They also propose to buy and download existing libraries of assets. But I did not look into that too much or how you could submit your own designs.) And lastly, for all the elements in a design that you can select, they show you what are the CSS rules you need to write to have that same element behave the same way in a web page. Kind of nice. Especially for positioning.

So, for every (adobe) file you upload, you can see some meta data, quickly access the major colors present in the design, leave comments for collaborators, extract assets, share the design on Behance and see the previous versions of the file. But don’t expect a reliable versioning system here. After 10 days, old versions are trashed.

After 10 days, we delete the past versions from the servers. If you know a version is going to be important, we suggest you make a copy of the current file you’re working on and save it with a new name. Then restore the original file back to the revision you care about. This way both copies become their own unique file that won’t be deleted automatically.

10 days is… ridiculous. And the solution proposed here kills all the benefits of using a versioning system. So let’s call this a short term memory backup, shall we. Nothing more. Why would you want to come back to a previous version of a design after 10 days, right?

Anyway, now on to the weird parts.

You know unix’s philosophy: everything is a file. Well, in the Adobe cloud, everything is an image. And if it’s not, it’s a blob. So yes, any .doc or plain .txt file is rendered as an image… Making it − if not unreadable, at least − unusable. HTML, CSS and Javascript are blobs. No way to see what’s inside them from the web interface. No versioning either (sorry, short term memory backup) for those. I’m not making this up. This is super strange. Adobe has a long list of tools related to web design, but displaying code in a web interface and versioning it, why would you want that, right?

In the little application you install on your desktop, you get real-time notifications when a collaborator leaves a comment, but they don’t tell you which file has changed and who did the changes. So apart from the comments, the app is just there to do the syncing and let you access the Adobe market for apps, fonts, stock photos and assets libraries. You can also see a preview of what’s trending on Behance. (Mmmh actually, there is a way to see which files have changed, but good luck on finding where that is. Tip: it’s not in the notification window.) So to sum it up, this is more like a market place for the Adobe products than a tool to communicate and collaborate, as I thought it could be.

I’ve only tested graphic files. More tests could be made with InDesign files, Premiere, After Effects or Flash. But I’m kind of focusing from a web designer point of view. So I also tested some other file types: .odf (Libre Office), .xcf (Gimp) and .py (Python) and unsurprisingly, they are all treated as blobs. With SVG, it’s a special case. They all are rendered correctly, but the features you can have with them are very different if you have saved them from Illustrator or from Inkscape, for example. The latter having the less feature, of course.

To wrap up, I’d say that the tool to extract assets is really a nice productivity improvement, but the syncing and collaborative features are behind what Dropbox is proposing. And since Dropbox just acquired Pixelapse, they really aim at offering an even better experience to designers, if they are not the tool of choice in that field already. Adobe is forcing its tool on everybody, of course, because you need that little app to install the Photoshop and others, but they need to polish it a lot more to get the designers to give them their files. And I don’t think that the “Publish on Behance” button is really a key here. But lets see how that evolves over time.

(Next episode: The Git Hosters )

Collaborative tools for designers: part 4

TL;DR: Tools I will not review and why.

Three weeks ago, I started a series of publications regarding tools that encourage collaborative practices for designers and that use some form of versioning at their core. You can read the previous chapters and especially the first one to understand what I’m looking for (links to part 2 and part 3). In this fourth episode, I’m just going to list tools I will not review thoroughly but that I felt I should mention because they exist (or existed) for certain reasons. If you have experience with some of them, I’d certainly be happy to hear about it.

Perforce

Used by blockbuster media companies (such as Rockstar Games or Disney, for example), it’s a complete project, team, assets, source control management solution aimed at very large studios with hundreds or thousands employees and its apparently great at handling large (sets of) media files (at least, that’s how it was once presented to me). The licensing fee are relative to that description. It’s worth noting that the latest presentation of Perforce Helix mentions the integration of Git for the developers in the team. Maybe worth watching is this video showing how to handle their image diff tool.

Layervault

Although, like Pixelapse, I had them on my watch list, I never took the time to dig deep into their product. And unfortunately, as I understand it from the description on their website, the company went bankrupt 6 months ago. Too bad, when you see Kelly Sutton present their product just 2 years ago, it looked very interesting. Their “wormhole” tool (at 6:00) is really a nice approach to get “what changed and when” in an image.

InVision

I hesitated for a while. Should I review this tool or not. They call themselves “The world’s leading prototyping, collaboration & workflow platform“, and looking at their client portfolio, they surely can pretend to this, I guess. But they focus mainly on screen based media and interactivity, or so it seems. and their level of version control is no better than Dropbox or similar. So the designers targeted here are “application” designers, UX/UI designers,… and I’m looking for a a less opinionated tool. Anyway. If you want to get a quick glance at what this tool does, here’s a quick introductory video. Certainly a great tool to review designs, manage projects & teams and test user experience. Not what I’m looking for atm.

Visual Culture

Visual Culture is a server software developed by Open Source Publishing to visualize git repositories. Since their design practice involves doing things open and in the open, their website runs on it and allows the visitor to browse into their latest projects and how those are made. Their intention was to turn it into a general tool for designers and they opened a crowdfunding campaign to achieve that goal, but this did not received enough support. I did try to install it and see how I could use it on my own projects. With the help from Colm, Stéphanie and Eric, I passed through a couple of bugs and misunderstandings on my part. And I could see a recap’ page of what I had in my folders. Unfortunately, that’s how far I managed to go. I lack some Django knowledge to adapt the necessary bits so it would behave nicely with my projects as, at this stage, Visual Culture is still very closely knitted to (how) OSP(‘s) work.

Come back next week for another chapter.

Collaborative tools for designers – Part 3 : Pixelapse

Reviewing tools for collaborative practices and version control for designers, this is episode III. And to my surprise, I’ve discovered Pixelapse, an online tool that promises to do just that.

It’s been a while since I had found about Pixelapse, but never took the chance to study it deeper until last week. Mainly because they require to install some software that only works for Mac and Windows. And since I use Linux, well…

So I borrowed a Mac without much luck either. Pixelapse software requires Mac OSX 10.7 and higher. The Mac was running on 10.6. I know designers have usually high end machines with latest software installed. But no Linux support and only a recent OSX, that’s 2 wall hits for me before even starting. But anyway, solved this by installing a Ms Windows running in a Virtual Machine under Linux because I really wanted to see how their tool worked. A pretty big setup just to sync files and not practical in the long term, but for the love of testing, it was fun enough.

Basically, what you are installing is a synchronizing software. Just like Dropbox, it creates a special folder on your machine, where you will keep your files synchronized with their servers and with the other computers you share that folder with. The other computers could be yours or from the designers that you want to work with. Apart from that, all the features proposed by Pixelapse run in the browser. Well, not every browser. Seems they only fully support Chrome. Internet Explorer is a no go and I don’t blame them for that (I tested IE11 only). Firefox seems to work ok, except for the “image inspector”, and that’s a pretty big feature being broken for no apparent reason.

About the features, they have really though it through. You can see their service as being between a version control, a project management and a reviewing tool. You can define roles for each projects, invite “clients” to review your graphic files and comment on them, or have collaborators with {full|limited} permissions. They support a wide variety of file formats for preview (mostly Adobe stuff), but also open file formats and even .xcf (Gimp files), although the latter did not render text properly. Version control is basic (no concurrent versions and they don’t allow custom naming your versions, so you’re stuck with version1,2,3,…) but at least they allow you to rename and move files around without losing their history and you can flag “milestones” in your project’s history. They also allow you to visually compare files or file versions in different ways. Commenting and reviewing design seems pretty well made, Although I could not test it on an actual project or with a team as I don’t know anyone who’s using this tool.

So my overall feeling is very positive, but something is bothering me. Apart from the fact that it’s not open source, not working on all systems and that you have to trust them with your files, why did I not hear of them more? If I had to do a comparison, I’d say this aims to be the Github for graphic designers, but why don’t I see more of us use it? As a matter of fact, I will definitely find more graphic design projects on Github than on Pixelapse. Why is that? They do allow public projects for free accounts. They encourage in their communication to do open source design projects. They feature some on their homepage. But after going through what was available publicly, I did not see much collaboration going on (Googling through the website, I found one public project with 8 participants. But can’t figure out if there was any collaboration at all. And then this UFO, which seems to put to good use the features proposed, but I’m wondering if this was really meant to be public). I know it’s a young service (2 yo), but Internet is pretty quick to embrace a pretty good idea when it sees one. Where is it not catching up?

I don’t have a definitive answer, but my feeling is that the interactivity is a little oversold and that it unfortunately still enforces the digital divide between coders and designers.

This tool is for graphic designers only, coders will not feel at home. Yes they support the viewing of some code files (HTML, CSS, JS), but without line numbering and a basic text diff tool, this is useless, even scary. Also, why not support other languages like, Ruby, Python or Bash scripting? Where is the problem with that? There are some good ideas : like having a README.md file and a cover image at the root of your project to automatically create a nice presentation page for your public projects. But then, without a proper way to see what changed in your markdown syntax, this becomes a little awkward to use.

The navigation has problems also. Exploring public projects is a pain. There is no search bar. You can add tags to your project’s description, but it’s like they forgot to implement it on the backend. No way to browse based on project type or keywords. No way to see the latest activity on the site resulting in no sense of community. Seeing the public projects they feature, it feels more like Behance − or any portfolio you can name − than an “Open Design Movement”, as they want to call it.

The interface is also a drag sometimes. It’s using animations here and there and this makes it all a bit clumsy. I want my tool to be fast and to the point. Animating between a thumbnail view and a list view of my files is not something I find important or informative. I wish also that space would be used more efficiently. The whole window is used when previewing files, comparing and reviewing them. And this is a good thing. But why do I feel that so much space is lost when I’m navigating folders and projects. Why not have the full screen used also for that too? I also found myself clicking a lot − where there was no button − expecting something to happen. At other times, I was completely lost and had to go back to the main page to start again.

Maybe it also tries to embrace to much. Working with clients is not the same as working within a “private” team and not close to working with strangers on open source projects. Keeping designers distant from coders is a also counter productive approach in my opinion.

The good news (or the bad news, depends on the point of view, I guess), is that Pixelapse has just been acquired by Dropbox. So it could mean that Dropbox will improve or that Pixelapse will support more operating systems. I’m guessing Dropbox is interested in the visual reviewing tools since they’ve just started introducing a commenting system for their files. As for the future of Pixelapse, Here’s what they have to say about it:

Will Pixelapse continue to operate?

Pixelapse as a standalone product will continue to be available and supported for the next year as we work towards bringing the same kinds of collaboration and workflow experiences that you’re used to in Pixelapse over to the core Dropbox product.

That just sounds to me as “good bye and thanks for all the fish”. I don’t expect Pixelapse being updated for the next year and have not seen a post on their blog or twitter since the Dropbox announcement (and that was 6 months ago).

There is a ton of good ideas in Pixelapse. But it needs polishing and a different approach regarding their community if they really want to be the repository platform of the “open design movement”. So for me, I’ll just pass and move on.

Collaborative tools for designers – Part 2 : Dropbox

Last week, I promised I would be exploring some of the tools promoted as helping designers in their revision control and collaborative process and that I would do this by comparing them to a list of benefits I extracted from my use of Git. So in this post, I’ll be reviewing the (in-?) famous Dropbox.

As a foreword, I have to tell you I don’t use their service. I was forced to have an account, when some friends and coworkers wanted to share some files with me, but I never liked the idea of having my draft files on a computer I did not own. I use some third party services to share publicly some projects, as you will find on Github, for example. But by default giving to a stranger a work in progress, some first sketches or an unpublished project, is not something I find comfortable. How good or easy the service could be.

So as a start, this rules out the use of Dropbox if you work under an NDA, have company secrets or just care about the keeping your working process to yourself or your collaborators. But let’s analyze what they offer and see how that helps designers or not.

First of, it’s an easy set up. After a necessary software install, sharing a project between collaborators is as easy as moving around a folder in a file explorer. It’s also “operating system agnostic” as it will work on Mac, Windows or Linux and even Android or iOS. And if that’s not enough, there is always the web interface to rely on. Actually, the web interface is where most features are built in. (I’m testing this from a Linux computer, but I guess it behaves similarly on other systems).

On the “workstation side”, there is not much more than moving around files, renaming them, and modifying them with your software of choice. It will then synchronize those changes automatically with all the computers you share that folder with.

On the “web side”, Dropbox offers you some form of “versioning”. Everytime you save your file, Dropbox records a change. You can go back in the history of those changes in the web interface and see who made them, from which machine. But unless you know what changes where made and when, there is not much more info given.

See for yourself, that list of versions is not that useful. If I did a mistake and saved over my file, I could use this to immediately revert to a previous version. But come back to that a week or a month later and who knows what’s hiding behind “version2”. If the file type is supported by Dropbox, I can see a preview by clicking on the version name in the browser. If not, I’m presented with a download button and have to open it on my computer. If somehow we could add a comment or a note with each version, that would improve this a little.

Also, there is no way to compare different versions (even if it’s a plain text file) except by viewing each independently − opening multiple browser windows − and figuring out for yourself what might have changed. Forget also about having different concurrent version of the same file. You’ll have to create different files for that and you’re back to your weird naming scheme. And if you rename your file or move it to a subfolder, your going to be losing all its history. Really? How useful is that?

So this revision system is more like a notification system of who worked on what and when, than a reliable way to store your changes as this can be wiped out by just renaming a folder. It does not help you get organized either. And I found the links in the “events” page confusing and practically useless, especially if you have a lot of files and subfolders in your main shared folder. (see screenshot below, all these files are located in different subfolders in a master folder called “libre-objet”).

(For some reason, I notifies me of changes on some these files, but when I’m clicking to view the history of it, it only says “version1”. Was the file renamed at some point, or the containing folder, or because those modifications were done before the folder was shared with me,… I have no idea. But how can I trust this?)

I did appreciate though that I could get a 1:1 preview of some files like SVG, Tiff, Jpeg, png, ai or psd (I did not review all the possible files formats). That 1:1 preview also features a commenting system, where you can tag collaborators. But I did not see any tool to annotate a design for example. Maybe that’s coming… who knows.

It also shows a little thumbnail for some of those file types. That’s handy. But this is also something I get in my file explorer on my computer, so where is the added value here? Why not also have those thumbnails in the history page next to each version, or in the event page also? That would be a little more helpful.

As a conclusion, Dropbox is maybe, for most, an easy way to get a shared folder on many different machines but it can not be trusted. Neither on the conservation of files, nor on keeping a history of changes. If you don’t care about “versioning”, you’ll be better of with alternatives, such as BtSync (closed source) or SyncThing (open source) and all the other self-hosted “cloud” application suites.

I know I’m killing down here a great service for some of you. And Dropbox never pretended to be the git (or github) for designers, even if they seem to be heading in that direction somehow. But their versioning system is a joke. And I’m looking at all of this from a very particular point of view. Please, don’t hesitate to share your designer’s experience using Dropbox in the comments below, I’ll be happy to read it and it might help me understand parts I could have missed. Again, I barely use the service. And if you enjoyed this post, come back soon for part 3.

(Cover photo by Steven Caddy released under Creative Commons by-nc)

Collaborative tools for designers – Part 1

Since I’ve discovered and used distributed revision control in my day to day practice, I’ve been amazed by how much it has helped me getting more organized, stop worrying about loosing files and also encouraged me to experiment more and thus try more options in my work. And I’m not even talking about how it eased the collaboration process with other designers and coders.

But one of the major drawback is to convince other people to use it. Convincing someone who codes already, or who is not afraid of typing commands in a console, was easy. But talking just pure GUI fanatics to jump into it, is a bit harder. And for a good reason. The tools needed to manipulate the usual revision control systems are mainly designed for coders. Yes, there are some GUIs (I don’t use them), but they look like a spreadsheet or a Soyuz cockpit. And that barely helps make sense when you are looking at the type of projects that graphic designers have to cope with.

So, I’ve been trying to put my head around this problem and come up with solutions. I had a first try at it with a project called “Design with Git” that I had the chance to develop at Medialab Prado, Madrid in 2013. But this was just a beginning, a short-time experiment, and although I’ve spent energy applying to other residency programs to continue on building it, I’ve yet to find a place that would allow me to dedicate some time improving this concept.

So, since this subject is not dead for me and for a lot of others, I’ve decided to start a series of blog posts, in which I would clear my head out and put into words and graphics my thoughts around this subject. And as a start, in the coming posts, I’m planning to review some available tools for “revision control” and collaboration between designers.

A word of warning here, maybe. I’m biased by my experiences, of course. And so far, the only version control system I’ve used extensively is Git. When I started being interested in these kind of tools, I got my hands on CVS, but then Git (and Github) quickly became the trending thing and I drank the Kool-Aid. Also, CVS needed a server, and that was too much to set up for me just to manage my own projects. I’m not a Git-guru either. I use it, almost daily, for almost all the things I produce. But I’ve not gone beyond the basics of cloning, branching, diffing, pushing and merging. When I have to do more complex tasks like going back to an older version of my files or completely erase a file from history, Stackoverflow is my friend.

So here is a list of what I find useful when using Git with my projects:

It allows me to view a history of changes, which files have changed and a written description about it (status / log)
It allows me to easily make different versions of the same project and to quickly switch between those versions (branch)
It allows me to work with an undefinite number of people (clone / fetch)
It returns precise and valuable information between the changes or different version of the project (diff)
It allows me to integrate the changes made by another person into my own project (merge)
It does not require a complex setup to start using it (init)
I do keep my folders tidy as I don’t have to invent complex naming formats for my files (No more Front-cover-v4a-TOPRINT2-validated.pdf)
It allows me to view the contributions of each participant on the project (log)
I’m not worried about loosing a file, erasing or writing over my previous work.
It eases the process of working with developers because we are sharing the same tool to keep track of the project’s advancement.

This list, I think, sums up for me what are the main benefits of using a distributed version system such as Git and these are the benefits graphic designers should get from using it also. The catch is this works well when you’re dealing with code or text files. But some points here are a little or very problematic when it comes to dealing with design files. Hopefully, there is some solutions or things that can be adapted. And I believe this is possible while keeping Git at the core of the process.

But before going further into this development, I’m planing to explore some of the tools promoted as helping designers in their revision control and collaborative process and I’ll do so using this list as a frame or a grid of evaluation.

So see you next time. (go to Part 2)

(Cover image: Soyuz cockpit by Christopher Michel under Creative Commons Attribution 2.0)