If I understand right the zipped2cloud way shares the drafted book with the teammates who can continue to develop the book with Bloom on their computer before it will be published to the library!?
I think this is really helpful for the Bloom booklet editors, who know Bloom.
But I guess in some cases - for critique from mothertongue speakers, for proofreading, or to inform the copyright holders - it would be helpful to be able to share a nearly finished Bloom Reader booklet draft with a few people.
Therefore for Bloom Reader booklets Iâd like to get the âprivate draftâ option too.
Thanks for your efforts.
@kklcclkk wrote
One question I have about zipping the books is and I recently I tried to zip up my book and send it to someone, but it did not allow me to zip it because I had used a certain diacritics that were not allowed in the names of files for zipped folders, apparently.
Right, that is a limitation of Windowâs built-in zipper. Instead, use 7Zip.
Right. Okay, so then for this Sharing Folder set-up will the built-in zipping process for Bloom include 7-Zip (or something similar that can handle diacritics) or will everyone who uses it in languages with such diacritics have to install 7Zip separately?
I am finding I wish I had this feature as well!
It only just came up, but it seems rather important for us.
Without it, it means editing will be done in word docs with no pictures.
Itâs a serious issue that impacts BLOOMâs usability.
I donât know how people are zipping, unless there are no special characters in their titles.
I donât know how people are zipping, unless there are no special characters in their titles.
7-ZIP doesnât have a problem with special characters. It integrates right into File Explorerâs right-click menu.
John, Iâm not sure where they went, but when you first floated this idea I myself responded favorably on the list, and Iâm sure that more than âseveralâ other people did also. Some of us have used up our several âvotesâ on the tracker site and can not use it anymore. Iâve been assuming that âsomeoneâ on this list is noticing when we reply âI would very much like this feature tooâ.
Thanks so much for your teamâs hard work on Bloom; we love it!
Please let us know when this feature for multiple people working on the same book or collection, in whatever form, might be available in Beta or even Alpha mode. Canât wait to use it!
Thanks so much!
Iâm doing some more design work on this âSave to Cloud Storage Featureâ, and I would appreciate some feedback. Consider these mockups:
In all versions, Bloom fills in the bookâs existing name, but you can edit it if you want. This is then followed, in grey, by a portion you cannot edit.
In version 1, the personâs name, the date, and the time are always added to the file, so that there are never conflicts with any existing files. If you save often, someone will probably want to eventually delete some of the various versions that will be accumulating.
In version 2, we let the user decide if they want to keep the file name unique like this. If they do not, then we need to deal with the situation where the file already exists, and may include changes that are incoming from a teammate (2B).
Iâm inclined to go with (1). Any objections or further thoughts?
Thanks.
I would say that if you go with a version 2 that you make it automatically checked. Then only people who are paying attention closely would hopefully be the ones who would unchecked it if they would have that situation where they would want to.
Could you explain a bit more what the user on the other end would see? You mentioned in an earlier post that the idea would be that a collection could be set up to watch a cloud storage folder and notify the user when a book arrives there so they can choose to add it to their collection. So with option 1 here, would that notification just tell them that a book called âMoon & Capâ (ie just the bold portion of the filename) has been added to their cloud storage folder, and ask if they want to add it to their local collection? Then if Bloom sees that the collection already contains a book called âMoon & Capâ, would it then ask if they want to update it? Or would the âreceivingâ user see that a book called âMoon & Cap_Name_Dateâ has been added to the shared folder, so when they add it to their collection they could have multiple books named âMoon & Cap_Name_Dateâ to decide between?
Could you explain a bit more what the user on the other end would see?
Hereâs the state of the idea at the moment:
The hardest part of all this is that, while we are making it easier to collaborate, we donât want to increase the chances that that two people will both work on the same book at the same time. Our current idea is to automatically create âlock filesâ in the sharing folder when you start editing a book. When you eventually tell Bloom to share your edits, that file goes away and so the file becomes âunlockedâ to the rest of your team.
Note, the above are live embeddings, so these images may change over time as the design is refined:
The âSave to Cloud Storage Folderâ dialog is currently out of favor. Instead we would just keep it all in this new âCloud Sharingâ box:
Someone wrote on email to ask about naming. Weâd let you set you name/nickname in the settings:
This is really exciting! It looks like a great approach and an intuitive implementation.
Would the collection-level settings (.bloomCollection & customCollectionStyles.css) be shared as well when a user chooses the âUse Cloud Sharing Folderâ option for a collection? Asking this because consultants who currently check books that are sent to them in a zip file see a different product when they drop them into a collection on their computer that specifies default fonts, front-matter arrangement, etc. that are different from the authorâs collection.
Would the collection-level settings (.bloomCollection & customCollectionStyles.css) be shared as well when a user chooses the âUse Cloud Sharing Folderâ option for a collection?
Thatâs not in scope yet, but I understand the need.
It would help me a lot to hear half a dozen people to tell me a story of how you collaborated on Bloom book.
Who did what?
How many back-and-forths were there where the book moved from machine to machine?
How did you work out who was allowed to be making changes, so that you didnât end up with two versions of the book?
If you donât have an actual story, an imagined one would also be helpful.
thanks!
Hereâs an alternative approach for your consideration.
Weâve shared books between computers both in the context of collaborating within our local team as well in the context of sharing books with a consultant for publication approval.
Within our local team, any one of the 4 of us who have Bloom installed on our computer may start a book from scratch or from a Shellbook. Others get involved to add images, review orthography, correct usage, add audio recordings, export the book to .bloomd, import it into a RAB project, etc. The back-and-forths with some books can be as low as 8 or 10, but I would say that they are usually in the dozens, maybe more in some cases. We handle this team collaboration by keeping our folder of Bloom collections on a NAS which syncs with a folder on each of our local computers. (The particular system we use is Synologyâs Drive Client). So as far as Bloom knows, it is working with a local folder on our computer. We are a small enough team that we can just let each other know which collection we are using so nobody else opens that collection on their computer until the Drive Client indicates that the synchronization is all up to date. A couple times there have been conflicts, but Synology just saves the file itâs unsure of alongside the current file with the filename_computername format for us to evaluate. The lockâfile proposal would help with that.
Sharing with a consultant doesnât happen until weâve printed some preliminary versions to test in the community and we feel pretty happy with the âpolishâ of the book. We tried zipping a single bookâs folder to send to the consultant but ran into differences in what they saw because of different collection settings, xMatter versions, etc, so what we did instead was to move all the books we want to have checked into a single collection, and then we zipped that collection for the consultant to unzip into their Bloom folder. There was no further back and forth for that check; they just sent us notes of things to change on our end.
Thanks so much for that Bruce, thatâs very helpful. Things to note (using some of the vocabulary Iâm playing with for this project):
- Uses a local server and LAN
- A whole collection is the unit of âcheck outâ, if you will
- Uses team communication to coordinate who has the collection âchecked outâ
- Normally 10-30 back-and-forths per book (<â this is a big eye opener for me)
Pain Points:
- During approval, need a separate, unwieldy system to share with consultant
- Very occasional conflicts when multiple people work on the same file, accidentally
Did I get that right or did I miss something important?
One way of looking at what we should be aiming for would be a system that is almost as convenient as what your team is doing, but which still works if the team is too spread out (or non-technical) to make use of a local NAS.
Yes, that looks like a good summary.
BTW, our number of back-and-forths may be much higher than others because each book for us is a team effort in a developing context. Weâre still using a âworkingâ but not officially âestablishedâ orthography, so we may need to update spelling/word-break choices more often than others. Weâre also producing materials for a few closely related languages, but they are still different enough that negotiating the best way to word things for the most people creates some extra back-and-forth too.
Using the LAN sync has worked pretty well for us locally, but the ability to easily share projects with consultants in a cloud folder will really make publication easier.