Kay C Lan wrote:
And now stepping on very thin ice I will go against the grain of 'User
Notes' as previously implemented and currently re-suggested. Again, as
an interim step I see them as very useful for capturing nuggets of
information. The great thing about them is, as stated by Jacque, you
don't need to learn any markup (or Git), and you can (could) do it
immediately.
IMO the ideal solution would be the Dictionary act like a Wiki Editor.
Those with Contributor Accounts get Edit buttons in each of the
relevant sections of each Dictionary entry. You want to add an
excellent example, then you click the Example section Edit button and
you add it right there, where it should be, and where it will be
automatically colour coded; not at the bottom of a dozen other
people's User Notes in lost black and white. You have a Warning,
Caution or Tip that needs highlighting, then that is how it's
presented; again not hidden amongst other User Notes in the same bland
font. Also, a one line Example entry would be just that, a one line
entry. The User Note format bloats it out with inclusion of who added
it, and a time stamp and a couple of blank lines around the entry so a
single line of relevance takes up 4 or 5 lines of Dictionary screen
space. I personally don't need my name attached to every contribution
I make - for those that do, maybe a list of Doc Contributor names in
the About Livecode box similar to the list of names of LC Community
contributors that currently appears.
The Dictionary is really only a glorified Wiki. I suspect most people
believe the success of Wikis is due to community contribution, but I
believe just as important is Wikis FORCE a standard format and
presentation, everything in it's right place, everything found where
it should be. I think one of the problems Richard alludes to re bloat
can be avoided if people are forced to think where exactly in the
Dictionary entry structure does my nugget of information fit in and
how do I word it so it does fit with the paragraph before and after.
As a bonus, you can also quickly correct that minor spelling error in
the preceding paragraph.
The Dictionary is just another Livecode stack, so this is all possible
with the talent and technology we have in front of us, the hardest
thing to implement would be the Git integration so that each
addition/amendment is vetted before inclusion with the next release
and visible to the rest of us.
Actually the biggest problem is who(s) is going to do build it. I
believe the Team is still looking for a Community Docs advocate/leader
to corral those with such inclinations and ideas. The reality is the
former idea of User Notes is probably a lot easier/quicker to
implement than turning the Dictionary into an .lcdoc Editor/Git
Integrator.
I should probably keep my big mouth shut from now on as the ice has
surely broken and I'm in very deep water.
Au contraire. I've quoted the meat of that post intact, long as it is,
because I feel it merits a second read. It's a very good collection of
ideas which, if implemented, could greatly streamline community
contributions to the Dictionary.
And like the rest of the clarity expressed there, you hit the hardest
part spot-on:
Actually the biggest problem is who(s) is going to do build it.
A project of this scope would be a considerable undertaking. The team
could do it, but it would need to go into queue after the current
objectives and the rest of the Kickstarter goals, so let's politely just
file that notion under "Not Soon". :)
The community could do it, but finding the intersection of interest,
skill, and available time would be at best very difficult. It's not
like one of the joyous one-offs we toss together, like Richmond's IDE
mods or my 20-line script that makes revMenubar look more Ubuntu-like.
This is a big task, big enough to warrant a team and a Gantt chart.
Conceiving such a system is brilliant but takes only a few minutes to
draft an outline like the one above. Drafting a functional spec and
workplan would take much more time, and coding it, testing it, and
building maintenance systems for it would be a pretty hefty commitment.
All of it is indeed very achievable in LiveCode. The project I work on
for emergency medicine is similar in scope, and all of it -- from the
client to the server all the way down to the data store and Web
publishing subsystem -- was built entirely in LiveCode. But it was
funded by a fairly large company with a clear upside for the investment.
Here the ROI is arguably strong but not quite as strong, when we
consider that Github's Markdown is fairly easy to learn and can be used
gracefully in any text editor, even their online form.
So I like the idea. Very much. And if we can get resources who could
commit to seeing it through I'd love to work with it. But the ROI may
be difficult to justify, as it would require a lot of people's time away
from other activities.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
