Hopefully, if a van rental company sees this and has some questions, we've got those questions and their answers covered here.
no, this is a working prototype to stimulate discussions on the required functionality.
no, I already have one of those ;) I see this as an opportunity for an interesting collaboration project.
I don't know yet. The aim is to provide a business (or businesses) with an effective way to enhance their customers' experiences and reduce support costs. They will then have opportunities to discuss how the product or its services are managed, and how these are licensed.
I expect it to be a very interactive collaboration. The rental company has the vehicles and is really the only one able to define what should be documented and how. They would then have to invest effort creating descriptions (in the languages they want to support) and the photos to illustrate the features of their vans.
The rental company is also completely in charge of how the site is structured, how many pages are required and their level of detail, the number of photos or illustrations and so on. Plus which language or languages need to be covered and how the translation process is organised.
Depending on how the rental company wants to divide up the work, perhaps they just want to deliver texts and receive websites, perhaps they also want the websites hosted, or perhaps they want to do everything themselves, including preparing the input files and running VanDocs. Currently that's very much open to discussion.
Smartphones are obviously the most important platform here, but VanDocs is agnostic. VanDocs does not run on a smartphone itself, but it generates websites which can be viewed on a smartphone, or viewed on a PC, laptop, tablet or any other device.
The prototype runs as a java CLI application on linux, using the website generator software hugo as one of the build steps. The whole thing could run on Windows or macOS too, if required. The resulting websites should be viewable on any browser on any OS.
To illustrate the multiple stages of the build process, we've established the concepts of workspace, hob, plate and table, using a kitchen analogy. The operator only cares about managing the workspace, and the customer only cares about just one of the plates on the table.
| Workspace | Hob | Plate | Table |
|---|---|---|---|
| All files for all languages, for all models | Constructed input files for a single model | Website for a single model | Collection of all websites |
| File fragments using markdown | Markdown | Html, Css, Images | Html, Css, Images |
| Input to VanDocs | Input to hugo | ||
| Manually edited | Written by VanDocs | Generated by hugo | Copied |
One important thing to note is that once the website is built, it becomes just a website delivered by a regular web server — there's no server side code, no database, no wordpress or php or any other framework to keep running. And this also means that the websites are fast and responsive, as well as portable and reliable.
As far as versioning goes, that's entirely up to the operator too, but it would be recommended to place the workspace under some kind of versioning system like git and regularly backed up.
I can't give a single number because it depends on what the operator wants. I imagine that the rental company won't want to run VanDocs themselves, but would prefer to pay a monthly fee for a service, where the rental company deliver the texts, images and specifications, and in return a complete set of multilingual websites is generated. And maybe also hosted. The cost of that service would depend on how many hours effort would be required to get the sites running and keep them updated. It is a priority that introducing new models should then require very little effort to add, as they will be able to reuse a lot of material from the existing models without duplication.
Aside from the direct costs, the operator will definitely have to invest their own effort at the beginning, preparing and checking the texts for inclusion, and reviewing the results. Like I said, an interesting collaboration project and not a "press one button and it's done" solution.
The information a customer needs before renting is not quite the same as the information they need after renting out on the road. Before I rent, I just want to know if the "large" model is the right one, does it have enough sleeping capacity and so on. At that stage I don't want to know how the leisure battery charges or where the light switch is in the bathroom. My focus is different, and I don't mind if information is general.
Out on the road, I want access to a lot more information, and I want it to be specific to the exact model (and variant) that I've been given. I want it detailed, and searchable.
Similarly, a lot of the information covered by this documentation will have been (briefly) covered in the introductory walkaround, but especially for a first-time renter, there's a bit of information overload on this quick runthrough, and sometimes the questions only arise after some days on tour, by which time some of the verbal instructions have been forgotten.
If the documentation generated by VanDocs is only available through the internet, then there are a few possible cases when they may not be accessible for the customer while on tour. Firstly, the customer may be using an internet connection with high costs or limited capacity when on holiday in another country. And secondly, they may be travelling in a remote region with limited cellphone signal.
One possible solution for this could be to serve the documentation from a webserver inside the van — perhaps a low-power raspberry pi zero offering a wifi hotspot and a simple web server. In this way all the information would be available over wifi without any internet connection. In fact, this was the first idea contributing to the birth of VanDocs.
The disadvantage with this solution, apart from the cost and effort of installing this hardware in every van, would be the difficulty of making sure the correct documentation is installed on each vehicle and the difficulty of updating or improving the documentation as necessary. For these reasons, and due to the diminishing costs of international internet access, it is thought that a centrally managed solution accessible over the internet would be the most effective deployment strategy.
It is also proposed that the van would have an information sheet placed prominently in the vehicle with a link (or QR code) to the model's (unique) documentation. This sheet would also identify the model uniquely in case it needs to be communicated to the support helpline should that be required.
Nothing, the name "VanDocs" just comes from a combination of "Van" (like campervan, like #vanlife) together with "Docs" (like documentation). It aims to produce documentation for campervans. Nothing to do with Vancouver, and nothing to do with repair or renovation services, or mobile medical facilities.
And yes, it should cover motorhomes equally as well as vans.