Hi Neil
I very much appreciate your thoughts and feedback, thank you.
* It's good and valuable that you can be a domain expert, and understand
> the boots-on-the-ground workflows, plus have software systems background.
>
> * Documents that are potentially much more complicated to support well,
> like contracts and court filings that you develop, are *not* within the
> scope of this work, correct?
>
Correct. At least, not for now. I can imagine extending support to more
complicated documents in the future, but that seems to me to be a separate
project or a little expansion.
> * I might normally start with asking about what you envision, and current
> workflow and tools, and raise examples to compare&contrast with (e.g., how
> does a DSL you envision compare with LaTeX document classes, or structures
> available in the tool that is used for other documents). The output is a
> better understanding of concept and requirements, as well as a start on
> analysis-level static and dynamic object models for the larger "system".
>
I am familiar with LaTeX, and more familiar actually with its cousin,
ConTeXt. Our current workflow is to draft documents in markdown with a YAML
header. That then gets processed by Pandoc and some homemade Bash into a
PDF through some Bash scripts.
* A big question is exactly how much do you want the system to understand
> about documents you receive from outside the system? (That is potentially
> not only a large amount of software in itself, but also multiple fields of
> ongoing research.)
>
I would expect my staff to write a document themselves (a "file note")
recording any relevant information from received documents. For example, if
we received a letter from the court telling us that we had a court hearing
then the person dealing with that letter would need to write a note
recording that.
* Usability by the all people who will be using it is important, of
> course. You might want to bounce sketches and mockups off them, and maybe
> you even end up doing "Wizard of Oz" simulated system usability exercises.
> And a DSL that might be ideal for you might turn out to be surprisingly
> disliked by some other lawyers/paralegals/secretaries. (Example: For a
> DSL, you might like S-expressions, Scribble, or SGML/XML, but it might turn
> out most of the users like something closer to Markdown, or a
> document-type-specific plain text format, such as one that can infer the
> addressee of a letter in markup-free rapid typing of plain text, or
> something closer to a WYSIWYG word processor, or something closer to a
> form, like the email header fields of an email composition window.)
>
Yes, we're only a small firm so it would be quite easy for me to canvas
opinions from my colleagues. Since they already use Markdown plus a YAML
header, a switch to Scribble style would not be much different. They are
already using text editors and have had to learn to deal with YAML
difficulties (e.g. you have to use quotes for the value if it has a colon
in it).
I actually think that free form text where the meaning was parsed through
its order might be quite nice. Something like: title, double new line,
date, new line, matter reference, new line, initials of author, double new
line, body of text, eof. It would of course mean that more work would be
required for each document parser and somehow it seems a little fragile to
me.
Scribble syntax is definitely what I want for the records, so that they can
be embedded in the text: "Spoke to the client by telephone. Confirmed I
would @todo[#:deadline "2018-08-28"]{send out the court form} on Tuesday.
The client gave me his mobile number: @contact["client/mobile"]{01234
567890}.
* Your application might have an advantage for DSL acceptance by
> non-programmers, in that many people in law offices have education that
> emphasizes logical reasoning. But don't underestimate the difficulty of
> skills familiar to programmers, if you try to get conceptually nontrivial.
> You can get most anyone to recognize concepts like Addressee, and you can
> tell/train them not to misuse semantics (e.g., don't put instructions to
> the mail carrier in the wrong semantic field, simply because you know it
> gets printed on the envelope). But non-programmers might have a surprising
> unfamiliarity with composition, abstraction, modularity,
> declarative/imperative distinction, kind-of/part-of, etc. I have anecdotes
> from industry and from research about this. (Someday, universal basic
> education in program design, with descendants of HtDP, will help. :)
>
Understood and thank you for this valuable advice. In my experience of
introducing my colleagues to new technologies, I've found that most just
want to be shown a workflow of how to use something and then they will
stick to that parrot-like in the future. We have run the office entirely on
open source software now for over two years. Generally, the attitude
amongst my colleagues is that we have the technological advantage over the
competition because we have more technical tools than they do.
My staff are keenly aware of the difficulties of knowledge working and I
would want to position this software as a tool that was going to help with
that.
> * Would this software also be the canonical place where objects like Case,
> Account, and Contact are defined and stored, or is there another software
> system for that, with which you'd want to integrate?
>
Our existing system would be subsumed into this. I would like Racket to be
the "one ring that rules them all".
> * Do you use a time time-tracking tool for this, and do you want to
> integrate with it (such as indicate to the user when the case(s) associated
> with the document they're reviewing disagree with what the time tracker
> thinks). Or do you want to implement a time tracking tool as part of this
> work.
>
We have a simple and basic time tracking system at the moment which works
simply on the naming of files with time tracking information. A bash script
then scans those files and creates relevant reports etc. My preference
would be to subsume this into the documents themselves in due course.
> * You mentioned querying for overdue tasks. How far do you want to get
> into project management -- like work breakdown, task dependencies,
> ordering, and resource allocations?
>
Simple task management would be sufficient for our purposes for the time
being: tasks, time estimates, person responsible, deadlines, and future
start dates. I think with all the record information I would start simple
so that it was easy to conceptualise and then only complicate it if there
was consensus from users that it would be required.
> * Once you know what to build, the sophistication of the resulting
> software might mostly be simple. The wins for working smart might be in
> the analysis&design, and then (if appropriate) clever "force multiplying"
> uses of Racket features, to build it rapidly and sustainably, with little
> resources. (It's also easy to imagine dozens of people building something
> like this, but that's probably not want you want, and they might have a
> harder time getting the "what" as right as a small team could.)
>
Absolutely. I was imagining, for example, that records could be modelled as
a struct. You make a struct for a task, and a macro creates record commands
to create, edit, delete and query task information. Then adding
appointments is just a question of a new struct and running the same macro
on it. Indeed, individual businesses could then tailor the package for
themselves as needed this way.
> * This might be the kind of thing that one organization with domain
> knowledge develops in-house for its own use, and then productizes for
> similar organizations. Sometimes those businesses go huge. If you're
> thinking that route, then you might want to do market research and
> competitive analysis early on. (I might be able to consult professionally
> on a funded commercial effort, beyond what I can do as an off-the-cuff
> community-sharing email.)
>
The purpose of this project is to support my existing business providing
legal services rather than to create a new software venture. My initial
plan would be to create an open source project in the hope that it would
benefit others businesses and perhaps attract contributions. I also hope
that it might bring users to Racket.
If someone else wanted to use me as a domain expert and then develop it
closed source for them to market, then that is something that I would
consider. But my guess is that would be a much bigger enterprise involving
market research etc. For the purposes of my own business, I know what small
steps we could take immediately that would be useful based on the
difficulties and limitations of our existing workflow.
In terms of consulting, I'd be happy for you to send me some information
off list. I'm not sure that's a route that I would be able to go down
because of the size of my business (think Better Call Saul, rather than
Suits), but I'd be happy to have some information so I can see whether or
not it might be an option.
Again many thanks for your time and thoughts.
Richard
--
Redwood Legal
r...@redwoodlegal.co.uk
Office: 01157 323277
15 Clarendon Street, Nottingham, NG1 5HR
This firm is authorised and regulated by the Solicitors Regulation
Authority (SRA ID 637939)
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
