We have clients with lots of attachments - this is not a "what if" situation. It certainly would be useful for our ICROA client. 

So ICROA has asked us specifically to solve an issue they have with sharing 100+ files? I'm curious why they've come to us with that problem instead of using microsoft one drive, google drive, dropbox or some project management app that includes solutions for file sharing (asana, basecamp, something from microsoft, etc).

Could you elaborate on why a more conventional file sharing solution isn't appropriate for their use case and why that feature should live inside of ScribeHub?

Hi Josh, the actual situation is not that ICROA asked us to specifically solve 100+ files to share/attach. If you look at the ICROA Organization workspace on Collaborase you will see the complexity of the use case. ICROA is actually the best example of one of the use cases for Collaborase (and subsequently ScribeHub). Not only is ICROA the best use case (for getting serious value from an online software with structured feedback), it is by far and away the best money-maker using Collaborase. We charge $3000 USD per year for each of the "reporting companies" (there are 13 or more companies) - the total is about $40000 USD per year - ICROA has been clients for 6 years (which is a loyalty/stickiness that few other users can come close to). To justify the $3000 USD cost, using the software is part of a service engagement ... after each of the reporting companies writes their content into Collaborase, and attaches their supporting documents (which is getting to be a a lot for each company), ClimateCHECK evaluates the content written by the reporting companies (ClimateCHECK's evaluation is actually an audit of the reporting company's content). ClimateCHECK makes a profit on each company - actually a better profit margin using Collaborase (probably 40% or higher) than without Collaborase (perhaps 25%). This is another reason we cannot let Collaborase die-off without ScribeHub having comparable tools.

We have other users that are becoming more active. An example is Ira Feldman - an American university professor that uses Collaborase to support a more efficient (for both the students and for him to manage/mark the work). Actually, Ira has told me that Collaborase was so enjoyable for students in past courses (and enhanced the learning experience; I've had the same feedback from a UK university), that he considers it to be a key reason for the ongoing demand for the course - this is not an exaggeration. In his Collaborase documents, the students are mainly using the Comment tool to write content and upload files.

All that to say, ScribeHub should:

1. have the list of attachments (much like you have)
2. users should be able to upload attachments in 2 ways:
   1. as you have now
   2. also when posting an issue (like in Collaborase); these attachments also get displayed as a link in the attachments list
3. when the list of attachments exceeds a threshold (e.g. 10 or 20), then there should be a link that goes to a page like the Issues page.
4. the "attachments page" (like in Collaborase, but we need it to be better) could be a table and displaying the basic info:
   1. file name
   2. name of user that uploaded the file
   3. timestamp the file was uploaded
5. the attachment table should be sortable, e.g. file name alphabetically, user name alphabetically, or newest to oldest for timestamp (Which I think should be the default sorting of the attachments)
6. Only the document owner/author and the user that uploaded that attachment can remove that attachment (i.e. another user/reviewer should not be able to delete an attachment uploaded by other user/reviewer)

This is a good level of detail for attachment use cases. It would have been most helpful to have it back in September 2018 when the "Document Attachments/Resources" feature was being defined. Initially I was planning on making a resources tab, but I wanted to simplify it and make it more like related documents. I didn't believe there was sufficient need to make it a tab. I still don't, but I think a searchable list in a modal is an acceptable solution for when there's more than 20 or so attachments. That will have to happen later in the year.

It would be a good exercise to conduct a post-mortem on the old software with Lisa and Pat and get on the same page about what went well and what didn't. That's another thing that would have been good to do early last year instead of right before or after soft launch, but it would still be good to do at this point. I've been trying to find resources about product design so we can get on the same page philosophically. That was what I was attempting to do with the "Collaborase 3 Philosophy" document, but I think it will have more weight when put in the context of successful products and when written by authors more skilled than I.

I found 3 recommended books about product design and usability approach:

1. The Inmates are Running the Asylum. Written by the inventor of Visual Basic. It illustrates the insanity that is users adapting to technology instead of the other way around and underlines usability as the most important aspect of any software.
2. Fifty Quick Ideas to Improve Your User Stories. I've been told this book is poorly named and does go into deep detail on what a user story is and how to determine if a problem has been boiled down to it's constituent parts.
3. Shape Up. This is written by the inventor of Rails and the CEO of the Basecamp family of products. If you pick just one of these to read, then I think it should be this one. It also happens to be free. It goes into great detail about how Basecamp determines if a feature should make it into their product.

The attachments feature was expanded to include thumbnails, names, descriptions and a filter field. This dramatically increases the organization of attachments without having to make it a tab. We can also attach files to comments and their replies, which means users can reference materials where the discussion is happening instead of dumping it all into one pile associated with the document.