data entry gui for transcription

[Peter]

Can anyone suggest a good simple software tool for transcribing records?
The application is to transcribe BDM, schools admission, ships passenger
lists, etc. We have a number of volunteer transcribers, and it would
really help to have a user friendly tool they can use. These folk have a
variety of PCs; WinXP, Win2000, Win98, Mac, Linux.

Output can be a simply fixed field length plain text file.
The user interface and the dta field lengths will change depending on which
transcription project we are doing.

Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.

TIA

Peter

[Steve Hayes]

On Sat, 06 May 2006 16:35:01 +1200, Peter <[email protected]> wrote:

Steve Hayes wrote:
On Sat, 06 May 2006 14:29:06 +1200, Peter <[email protected]> wrote:
Can anyone suggest a good simple software tool for transcribing records?
The application is to transcribe BDM, schools admission, ships passenger
lists, etc. We have a number of volunteer transcribers, and it would
really help to have a user friendly tool they can use. These folk have a
variety of PCs; WinXP, Win2000, Win98, Mac, Linux.

Custodian?

That one looks rather expensive if we needed to buy multiple copies (plus it
doesn't seem to work on Mac or Linux).
It looks like it has lots of features, but perhaps more than we are looking
for.

How are you saving the transcribed information?

I suggested Custodian because it's the only program I know that is designed to
do anything like that. I once helped to design a cemetery transcription
program, but designing something to transcribe many different kinds of recrods
is rather more comples, and making it multi-platform is more complex still.
Perhaps you could design something in OpenOffice Base?


--
Steve Hayes from Tshwane, South Africa
http://www.geocities.com/Athens/7734/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[Peter]

Steve Hayes wrote:

How are you saving the transcribed information?

It is being used in dbf or mdb format. Once it is in a consistent
electronic format, it is relatively easy to move around.

I suggested Custodian because it's the only program I know that is
designed to do anything like that. I once helped to design a cemetery
transcription program, but designing something to transcribe many
different kinds of recrods is rather more comples, and making it
multi-platform is more complex still. Perhaps you could design something
in OpenOffice Base?

I was wondering about Base, but haven't used it before. I'm taking a look
at it now.

thanks

Peter

[Steve Hayes]

On Sat, 06 May 2006 18:13:28 +1200, Peter <[email protected]> wrote:

Steve Hayes wrote:
How are you saving the transcribed information?

It is being used in dbf or mdb format. Once it is in a consistent
electronic format, it is relatively easy to move around.

I suggested Custodian because it's the only program I know that is
designed to do anything like that. I once helped to design a cemetery
transcription program, but designing something to transcribe many
different kinds of recrods is rather more comples, and making it
multi-platform is more complex still. Perhaps you could design something
in OpenOffice Base?

I was wondering about Base, but haven't used it before. I'm taking a look
at it now.

You might like to join the Genealogy Software Development list:

http://groups.yahoo.com/group/gensoft/

for a more detailed discussion, including dataformats etc.


--
Steve Hayes from Tshwane, South Africa
http://www.geocities.com/Athens/7734/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[Hugh Watkins]

Peter wrote:

Can anyone suggest a good simple software tool for transcribing records?
The application is to transcribe BDM, schools admission, ships passenger
lists, etc. We have a number of volunteer transcribers, and it would
really help to have a user friendly tool they can use. These folk have a
variety of PCs; WinXP, Win2000, Win98, Mac, Linux.

Output can be a simply fixed field length plain text file.
The user interface and the dta field lengths will change depending on which
transcription project we are doing.

Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.

spread sheet csv

open office

or sun java office

Hugh W

[Robert Melson]

In article <[email protected]>,
Hugh Watkins <[email protected]> writes:

Peter wrote:

Can anyone suggest a good simple software tool for transcribing records?
The application is to transcribe BDM, schools admission, ships passenger
lists, etc. We have a number of volunteer transcribers, and it would
really help to have a user friendly tool they can use. These folk have a
variety of PCs; WinXP, Win2000, Win98, Mac, Linux.

Output can be a simply fixed field length plain text file.
The user interface and the dta field lengths will change depending on which
transcription project we are doing.

Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.

spread sheet csv

open office

or sun java office

Hugh W

How much development work are you willing to consider? Seems to me you might
want to consider something web-based, since it's likely that everybody will
have a browser. With a web-based approach, you run your interface as an
application on a web-server, which cuts out the incompatibility problennm and
have the advantage of centralized storage. From what you say, the "template"
wouldn't have to be particularly complex, so development time and effort would
probably be minimal. For ideas on how to do this, check out "Web Database
applications with PHP and MySQL", Hugh Williams & Donald Land, O'Reilly, 2002,
ISBN 0-596-00543-1.

HTH,
Bob Melson


--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"When bad men combine, the good must associate; else they will fall one by one, an unpitied
sacrifice in a contemptible struggle." ---Edmund Burke
-----

[Hugh Watkins]

Robert Melson wrote:

In article <[email protected]>,
Hugh Watkins <[email protected]> writes:

Peter wrote:


Can anyone suggest a good simple software tool for transcribing records?
The application is to transcribe BDM, schools admission, ships passenger
lists, etc. We have a number of volunteer transcribers, and it would
really help to have a user friendly tool they can use. These folk have a
variety of PCs; WinXP, Win2000, Win98, Mac, Linux.

Output can be a simply fixed field length plain text file.
The user interface and the dta field lengths will change depending on which
transcription project we are doing.

Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.

spread sheet csv

open office

or sun java office

Hugh W


How much development work are you willing to consider? Seems to me you might
want to consider something web-based, since it's likely that everybody will
have a browser. With a web-based approach, you run your interface as an
application on a web-server, which cuts out the incompatibility problennm and
have the advantage of centralized storage. From what you say, the "template"
wouldn't have to be particularly complex, so development time and effort would
probably be minimal. For ideas on how to do this, check out "Web Database
applications with PHP and MySQL", Hugh Williams & Donald Land, O'Reilly, 2002,
ISBN 0-596-00543-1.

a danish user is keen on TNG
http://lythgoes.net/genealogy/software.php

but what about when you die
who will maintain the site ?

Hugh W

[Robert Melson]

In article <[email protected]>,
Hugh Watkins <[email protected]> writes:

Robert Melson wrote:
snip
How much development work are you willing to consider? Seems to me you might
want to consider something web-based, since it's likely that everybody will
have a browser. With a web-based approach, you run your interface as an
application on a web-server, which cuts out the incompatibility problennm and
have the advantage of centralized storage. From what you say, the "template"
wouldn't have to be particularly complex, so development time and effort would
probably be minimal. For ideas on how to do this, check out "Web Database
applications with PHP and MySQL", Hugh Williams & Donald Land, O'Reilly, 2002,
ISBN 0-596-00543-1.


a danish user is keen on TNG
http://lythgoes.net/genealogy/software.php

but what about when you die
who will maintain the site ?

Hugh W



Given the initial query, I don't think the problem is one of longevity, either

of the application OR the user. Seems to me the advantage of the approach I've
suggested is that it is architecture neutral, in that it doesn't depend on a
specific spreadsheet or emulation thereof, centralizes data storage, can fairly
easily be customized to meet the group's needs. For that matter, it's not even
dependent on a specific web-server application and could use any of several
web development tools available. IMO, the flexibility offered by a web-based
approach makes it worthy of investigation/consideration, if not of adoption.
Moreover, since this is a specialized data-entry application, things like TNG
and phpGedView are inappropriate; although I like/use/host a phpGedView site
for my genealogical family, I don't believe it offers the facilities the OP
is looking for and would recommend neither it nor TNG in this specific
instance.

Hope this clarifies matters,
Bob Melson

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"When bad men combine, the good must associate; else they will fall one by one, an unpitied
sacrifice in a contemptible struggle." ---Edmund Burke
-----

[Peter]

Robert Melson wrote:

How much development work are you willing to consider? Seems to me you
might want to consider something web-based, since it's likely that
everybody will
have a browser. With a web-based approach, you run your interface as an
application on a web-server, which cuts out the incompatibility problennm
and have the advantage of centralized storage. From what you say, the
"template" wouldn't have to be particularly complex, so development time
and effort would probably be minimal.

The web based approach won't really work. This is in New Zealand, and
boardband isn't widely available, most people have only dial up access to
the internet.

I was thinking of a simple tool that would give the user a form with fields
to fill in, and it would put the data into a file. Then it is just a
matter of combining these files from all the volunteers.

thanks anyway

Peter

[Peter]

Hugh Watkins wrote:

spread sheet csv

open office

or sun java office

Yes, we have been using whatever people have on their PCs; Works, Excel,
dBase, Word, Access, etc. It hasn't worked too well, as the file formats
are too diverse, and it is too easy for people to get field formats wrong.

OpenOffice would be ok, except it is too heavy for some of the older PCs
running Win98 etc.

thanks anyway

Peter

[Gjest]

On Sun, 07 May 2006 08:37:30 +1200, Peter <[email protected]>
wrote:

The web based approach won't really work. This is in New Zealand, and
boardband isn't widely available, most people have only dial up access to
the internet.

You don't need broadband to do what Robert has suggested.

--

Dennis K.

[Robert Melson]

In article <[email protected]>,
Peter <[email protected]> writes:

Robert Melson wrote:
How much development work are you willing to consider? Seems to me you
might want to consider something web-based, since it's likely that
everybody will
have a browser. With a web-based approach, you run your interface as an
application on a web-server, which cuts out the incompatibility problennm
and have the advantage of centralized storage. From what you say, the
"template" wouldn't have to be particularly complex, so development time
and effort would probably be minimal.

The web based approach won't really work. This is in New Zealand, and
boardband isn't widely available, most people have only dial up access to
the internet.

I was thinking of a simple tool that would give the user a form with fields
to fill in, and it would put the data into a file. Then it is just a
matter of combining these files from all the volunteers.

thanks anyway

Peter


Pity, that.

I know of nothing that would meet your needs out of the box, given what you've
said here and in response to Hugh's spreadsheet suggestion. If the members of
your group are willing to install perl on their local machines, you might be
able to craft one or more fairly simple data entry scripts for them to run.
That'd standardize storage layout, at least, and give you a fighting chance
later on at combining the various submissions relatively painlessly.

As a further (last) pitch for a web based approach, it seems to me that, unless
you pay by the amount of connect time, internet speed is not really an issue -
you're dealing with a relatively small amount of information being transferred
from a local browser to a central server. The date-entry form has to be sent
from the server to the local browser, but the data is entered locally at what-
ever speed the local machine is capable of; the data is not transferred as you
type it, but only on command ("submit", "ok", "enter", whatever you choose).
In my opinion, this - or a similar - approach is about the only way you're
going to be able to get past the huge incompatibilities between operating
systems and applications. I certainly won't sit here and claim it will be
painless - somebody's got to program the application(s), there has to be a
server maintained by somebody, network speed will certainly have an impact,
tho' not so great as you might expect. I think the advantages of centralized
storage, consistent data-entry format, ability to customize and, believe it or
not, simplicity just might outweigh the perceived disadvantages.

I clearly have no stake in this, whichever way you decide to go, but honestly
do believe you should give a bit more - and more serious - consideration to
the web-based approach.

If you have questions or would like to discuss this further off-group, I'd be
most happy to hear from you by email. My address is as shown in the "Reply-To"
line in the header. (Contrariwise, if you think I'm just baying at the moon,
keep that to yourself, please.)


Regards,
Bob Melson


--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"When bad men combine, the good must associate; else they will fall one by one, an unpitied
sacrifice in a contemptible struggle." ---Edmund Burke
-----

[Paul Blair]

Peter wrote:

Hugh Watkins wrote:
spread sheet csv

open office

or sun java office

Yes, we have been using whatever people have on their PCs; Works, Excel,
dBase, Word, Access, etc. It hasn't worked too well, as the file formats
are too diverse, and it is too easy for people to get field formats wrong.

OpenOffice would be ok, except it is too heavy for some of the older PCs
running Win98 etc.

thanks anyway

Peter

Given the spread of machinery, operating systems etc, the web is the
only way to go.

This can be done on most servers using a form with user input fields, a
submit button, and a connection to send the data to (you?) in an email.
Easy to set up and use, provided (you?) don't mind transferring the info
provided into the final bucket. Even that could probably be automated...

Paul

[Steve Hayes]

On Sun, 07 May 2006 08:37:30 +1200, Peter <[email protected]> wrote:

Robert Melson wrote:
How much development work are you willing to consider? Seems to me you
might want to consider something web-based, since it's likely that
everybody will
have a browser. With a web-based approach, you run your interface as an
application on a web-server, which cuts out the incompatibility problennm
and have the advantage of centralized storage. From what you say, the
"template" wouldn't have to be particularly complex, so development time
and effort would probably be minimal.

The web based approach won't really work. This is in New Zealand, and
boardband isn't widely available, most people have only dial up access to
the internet.

I was thinking of a simple tool that would give the user a form with fields
to fill in, and it would put the data into a file. Then it is just a
matter of combining these files from all the volunteers.

Would there ve different kinds of files (or tables) for each type of
information source?

http://www.eastgate.com/Tinderbox/

Gives details of a Mac program that is soon to have a Windows version (doesn't
say anything about Linux, though). Is that the sort of thing you are looking
for?


--
Steve Hayes from Tshwane, South Africa
http://www.geocities.com/Athens/7734/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk

[Peter]

Robert Melson wrote:

As a further (last) pitch for a web based approach, it seems to me that,
unless you pay by the amount of connect time, internet speed is not really
an issue - you're dealing with a relatively small amount of information
being transferred from a local browser to a central server.

Web based approach doesn't seem viable, as I can't see our users sitting on
their dial up connection for hours at a time. However, I'll ask around and
see what folk think.

Otherwise, looks like we'll have to stick with the various apps that people
have already (Works, Excel, Word, etc).

thanks for your advice

Peter

[Robert Melson]

In article <[email protected]>,
Peter <[email protected]> writes:

Robert Melson wrote:
As a further (last) pitch for a web based approach, it seems to me that,
unless you pay by the amount of connect time, internet speed is not really
an issue - you're dealing with a relatively small amount of information
being transferred from a local browser to a central server.

Web based approach doesn't seem viable, as I can't see our users sitting on
their dial up connection for hours at a time. However, I'll ask around and
see what folk think.

Otherwise, looks like we'll have to stick with the various apps that people
have already (Works, Excel, Word, etc).

thanks for your advice

Peter

And, having made my pitch, I'll bow out now. My previous offer to "consult"
off-group stands.

Good luck,

Bob Melson

--
Robert G. Melson | Rio Grande MicroSolutions | El Paso, Texas
-----
"When bad men combine, the good must associate; else they will fall one by one, an unpitied
sacrifice in a contemptible struggle." ---Edmund Burke
-----

[Paul Blair]

Peter wrote:

Robert Melson wrote:
As a further (last) pitch for a web based approach, it seems to me that,
unless you pay by the amount of connect time, internet speed is not really
an issue - you're dealing with a relatively small amount of information
being transferred from a local browser to a central server.

Web based approach doesn't seem viable, as I can't see our users sitting on
their dial up connection for hours at a time. However, I'll ask around and
see what folk think.

Otherwise, looks like we'll have to stick with the various apps that people
have already (Works, Excel, Word, etc).

thanks for your advice

Peter

Do it off-line, send it on-line.

Paul

[Gjest]

On Sun, 07 May 2006 14:17:47 +1000, Paul Blair <[email protected]>
wrote:

Do it off-line, send it on-line.

Exactly. Transcribe into any text editor. Then go online, paste it into
a web form, and send.

--

Dennis K.

[mickg]

Look for something written in Java (not javascript) should run on most
systems if they install the java package from Sun.

MickG

Peter wrote:

Can anyone suggest a good simple software tool for transcribing records?
The application is to transcribe BDM, schools admission, ships passenger
lists, etc. We have a number of volunteer transcribers, and it would
really help to have a user friendly tool they can use. These folk have a
variety of PCs; WinXP, Win2000, Win98, Mac, Linux.

Output can be a simply fixed field length plain text file.
The user interface and the dta field lengths will change depending on which
transcription project we are doing.

Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.

TIA

Peter

[singhals]

Peter wrote:

Hugh Watkins wrote:

spread sheet csv

open office

or sun java office


Yes, we have been using whatever people have on their PCs; Works, Excel,
dBase, Word, Access, etc. It hasn't worked too well, as the file formats
are too diverse, and it is too easy for people to get field formats wrong.

OpenOffice would be ok, except it is too heavy for some of the older PCs
running Win98 etc.

thanks anyway

Peter

You might want to wander over to the USGenWeb Census Project and talk
the folks running it. When I did a couple census for them, they sent me
a template specific for each census and for my spread-sheet of choice.

Or, given what you're transcribing, think KISS-- use PAF, which is free
and has versions that run on a DOS XT. That'll cover just about any
system other than a MAC. Use the name field for, er, the index name,
the birthdate field for the doc date, the custom ID for an identifier
--L15f295 f'instance--, and the NOTES for the actual transcription.
Then key in ALL the names in the transcription as other individuals,
using the same date and custom ID. GEDCOM it out, use GED2XL (or
whatever the actual name _is_), Et voila! a transcription in a single
format you can manipulate from here to kingdom come.

Then, let your MAC transcribers use Clarisworks, and you'll be dealing
with only 2 distinct formats instead a dozen or more.

Cheryl

[Kerry Raymond]

Can anyone suggest a good simple software tool for transcribing records?

Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.

Herein lies the great curse of "inclusiveness" of genealogy societies. Often
there are volunteers for tasks, but most of whom come with complicating
constraints (ancient PCs, can't afford software, no Internet access, etc).
As the coordinator of the activity, you need to decide if you will:

* choose the lowest common denominator that everyone can support (probably
Notepad, or similar) -- problem is that the data will be highly
"unstructured" (stuff in the wrong "columns" etc)
* allow people to use "anything" they have -- problem is that combining
information is now extremely difficult
* pick the "best" solution and exclude volunteers who can't use that
technology for whatever reason -- problem is you derive yourself of willing
workers and possibly lose some goodwill for future projects from those
excluded

What is important here? Achieving an outcome, or being inclusive? Personally
I think it is the right thing to turn down an offer of help when there are
too many complications attached to it. If the person volunteering really
only has an ancient PC running Win3.1 and no Internet access (or whatever),
find them some other project to work on. Don't drag everyone else down to
their level. Don't tie up the coordinator's time doing file conversions etc.
Don't comprise the overall efficiency of the project for the sake of being
afraid to say "thanks but no thanks" to someone. Some people are a
hindrance, not a help. That's life.

Suggestion. It is quite feasible for a person to index a book as a
one-person project. Many otherwise useful books in a family history library
come without an index. Coming up with an index of names (which is usually
what people want for family history purposes) can be done in just about any
software. You simply have to be able to write:

Smith, John; 20
Brown, Mary; 21

or something like that and then someone sorts it alphabetically at the end.
Indexing a book is a task you could give to someone who can't easily
participate in a larger indexing project, and avoids turning away a
volunteer.

Kerry

[Hugh Watkins]

Kerry Raymond wrote:

Can anyone suggest a good simple software tool for transcribing records?


Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.


Herein lies the great curse of "inclusiveness" of genealogy societies. Often
there are volunteers for tasks, but most of whom come with complicating
constraints (ancient PCs, can't afford software, no Internet access, etc).
As the coordinator of the activity, you need to decide if you will:

* choose the lowest common denominator that everyone can support (probably
Notepad, or similar) -- problem is that the data will be highly
"unstructured" (stuff in the wrong "columns" etc)
* allow people to use "anything" they have -- problem is that combining
information is now extremely difficult
* pick the "best" solution and exclude volunteers who can't use that
technology for whatever reason -- problem is you derive yourself of willing
workers and possibly lose some goodwill for future projects from those
excluded

What is important here? Achieving an outcome, or being inclusive? Personally
I think it is the right thing to turn down an offer of help when there are
too many complications attached to it. If the person volunteering really
only has an ancient PC running Win3.1 and no Internet access (or whatever),
find them some other project to work on. Don't drag everyone else down to
their level. Don't tie up the coordinator's time doing file conversions etc.
Don't comprise the overall efficiency of the project for the sake of being
afraid to say "thanks but no thanks" to someone. Some people are a
hindrance, not a help. That's life.

Suggestion. It is quite feasible for a person to index a book as a
one-person project. Many otherwise useful books in a family history library
come without an index. Coming up with an index of names (which is usually
what people want for family history purposes) can be done in just about any
software. You simply have to be able to write:

Smith, John; 20
Brown, Mary; 21

or something like that and then someone sorts it alphabetically at the end.
Indexing a book is a task you could give to someone who can't easily
participate in a larger indexing project, and avoids turning away a
volunteer.

csv or spreadsheet ?

I know of several utilites created for specific census and parish
register projects in UK and DK

could your work also contribute?

Hugh W



daily blogs with new photos

http://slim2005.blogspot.com/
http://snaps2006.blogspot.com/

family history
http://hughw36.blogspot.com

[singhals]

Kerry Raymond wrote:

Can anyone suggest a good simple software tool for transcribing records?


Something open source would suit, as this is volunteer work, and we don't
have funds to buy software.


Herein lies the great curse of "inclusiveness" of genealogy societies. Often
there are volunteers for tasks, but most of whom come with complicating
constraints (ancient PCs, can't afford software, no Internet access, etc).
As the coordinator of the activity, you need to decide if you will:

* choose the lowest common denominator that everyone can support (probably
Notepad, or similar) -- problem is that the data will be highly
"unstructured" (stuff in the wrong "columns" etc)
* allow people to use "anything" they have -- problem is that combining
information is now extremely difficult
* pick the "best" solution and exclude volunteers who can't use that
technology for whatever reason -- problem is you derive yourself of willing
workers and possibly lose some goodwill for future projects from those
excluded

What is important here? Achieving an outcome, or being inclusive? Personally
I think it is the right thing to turn down an offer of help when there are
too many complications attached to it. If the person volunteering really
only has an ancient PC running Win3.1 and no Internet access (or whatever),
find them some other project to work on. Don't drag everyone else down to
their level. Don't tie up the coordinator's time doing file conversions etc.
Don't comprise the overall efficiency of the project for the sake of being
afraid to say "thanks but no thanks" to someone. Some people are a
hindrance, not a help. That's life.

Suggestion. It is quite feasible for a person to index a book as a
one-person project. Many otherwise useful books in a family history library
come without an index. Coming up with an index of names (which is usually
what people want for family history purposes) can be done in just about any
software. You simply have to be able to write:

Smith, John; 20
Brown, Mary; 21

or something like that and then someone sorts it alphabetically at the end.
Indexing a book is a task you could give to someone who can't easily
participate in a larger indexing project, and avoids turning away a
volunteer.

I've done a *lot* of indexing using a spreadsheet. When I need to merge
into what someone else has done, we each create a "save as csv" and
exchange; each of us then swaps and imports.

I've done a little indexing using NOTEPAD and inserting the , by hand as
I type. It works better for those who can count and think simultaneously

It's also possible to do it in a word-processing program as a table and
then doing a "sort as Text".

I prefer the spreadsheet approach.

Cheryl

[Steve Hayes]

On Sat, 01 Jul 2006 17:59:06 -0400, singhals <[email protected]> wrote:

I've done a *lot* of indexing using a spreadsheet. When I need to merge
into what someone else has done, we each create a "save as csv" and
exchange; each of us then swaps and imports.

I've done a little indexing using NOTEPAD and inserting the , by hand as
I type. It works better for those who can count and think simultaneously

It's also possible to do it in a word-processing program as a table and
then doing a "sort as Text".

I prefer the spreadsheet approach.

For a large project with many volunteers, it might be possible to write a
special program for the purpose. FreeBMD has such a program.

Older version of BASIC stored sequential access files in CSV format, and it
would be relatively easy to write a program for data input and thus ensure
consistency.

I don't know about new versions, like visual Basic -- but it does have all
kinds of provision for accessing database engines, so it should be possible.


--
Steve Hayes from Tshwane, South Africa
http://people.tribe.net/hayesstw
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk