Quick initial thoughts:
* 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?
* 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".
* 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.)
* 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.)
* 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. :)
* 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?
* 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.
* 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?
* 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.)
* 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.)
--
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.
