found at URL:
/awards/medals/tmed05star1.gif
/awards/ribbons/rib05star1.gif
What we have done for ourselves alone, dies with us. What we have done for others and the world, remains and stays immortal.
My working assumptions in this regard are that the Class officers will:
We may decide that some component(s) of the site should be secure,
accessible only by a password that would be obvious to classmates but
few
others. However, because we will probably NOT make e-mail addresses,
postal
addresses, or phone numbers available through the site, I hope there
will be
no need to have secure areas.
We should practice creeping gradualism and foster realistic expectations
with regard to content, functionality, and timing.
Once we have a decent amount of content in finished form, we can publicize
the site and our tentative plans for it, ask for feedback, then wait
to see
how our classmates react.
I suggest that our first step is to agree on the "Essential Content"
and a
general timetable for having each of these elements ready for view
by
visitors to the site.
I also welcome your comments
on the "desirable content" list.
A. Essential content:
1. Statement of purpose
2. Disclaimer re accuracy, content, etc.
3. Class officers' names and contact info (extent of info TBD)
[currently
showing names which mail link to each officer.]
4. Shipmate columns - full text of current and several past columns;
pop-up e-mail template for submitting news
5. Deceased classmates, with some details (e.g., date of death,
active duty status, service-connected cause)
6. Alphabetized class roster, with zip codes, USNA companies.
Include Honorary Classmates. Include non-graduates?
7. Class of 1963 Foundation component. Content to be developed
by the Foundation, approved by the Class.
8. Contacting classmates (How to obtain postal and e-mail addresses)
9. How to update your contact info
10. Links to web sites of interest
11. Class news and notices
B. Desirable content:
1. Searchable class roster, with zip codes, USNA companies, branch
of service, warfare specialty, etc.
2. Links to classmates' web sites
3. Classmates' valor - Navy Cross (3) and DSC (1) citations,
with Lucky Bag portraits
4. USS FITZGERALD info
5. Interesting facts and statistics about the class and our classmates
6. Photo gallery
7. List of '63 flag officers (with Lucky Bag portraits)
8. Generational connections ('63 descendants and ancestors who
attended USNA, USMA, USAFA, USCGA)
9. The '63 experience in Vietnam
10. Downloadable graphics (1963 crest, USNA seal, other USNA
and service-related items)
11. "In business" for info/links to classmates' enterprises
[limited
to link plus short phrase of business, e.g,Used
Car Sales ]
12. Personal news and notices
13. Sea Stories submitted by classmates
14. Bibliography -- items by '63 authors, items by other USNA
grads, items about USNA, other recommended titles. Include
print and other media
15. Info re major reunions
1. Establish an e-mail alerting service to tell classmates about
notable news and site updates
2. Make liberal use of quotes/epigrams/aphorisms interspersed
throughout the site
3. Keyworkers for specific areas (e.g., Shipmate, Foundation)
should be able to make updates themselves, with proper authentication
4. Audio would be highly desirable, but only with permissions
(We could, for example, show a legend saying that this music is from a
certain CD, available from the Alumni Association, with a link to ordering
info)
5. I like '64's scrolling "light bulb" banner for breaking news…
- NStar/MHS
It would help if we settled on a standard terminology for the various parts of the site, to be used by those of us working behind the scenes. To get this moving, I suggest we use a three-level model:
Home Page, Sections, and Pages.
For example, from the Home Page, one would move to one of the sections
which comprise the site, then to the desired page
within that section.
This makes perfect sense to me as proposed. Looking ahead it
serves a useful
purpose for me. Within Blackie's and my agreement on how we
migrate approved
material from the development site to the official site, he notifies
me what
to migrate. I need to organize the material with subdirectories
and other
techniques to keep it from becoming unwieldy (and, frankly, difficult
to tape
restore if something bad happens). If we use Home, Section,
and Page, Blackie
can tell me not only which element to migrate, but where it goes.
This will
minimize, if not eliminate, culture clash between the development
and the
production environments. - BK
Thoughts on Transition: [1 May 1999]
Grand Openings occur after the business is established.
The two primary requests we are making of our Class President are:
* Tacit approval of the concept of a Class web site
* Recognition that the Class web site is an extension of
the Secretary's responsibilities and authority.
Once we have those two, NStar is in charge. I then suggest this plan of action:
1] NStar sends to MAB, "I like what we have so far; move it all
at this time from development to production site, for our Validation Period."
MAB in turn notifies WLK who does so, with whatever testing, etc. is necessary.
[see Notes 2, 4]
In this final approval step, MAB confirms that's what he composed and
NStar confirms that's what he approved. This protects us from the
propellerhead smearing the entrails counterclockwise when the intent and
understanding was that they be smeared clockwise. BK
2] NStar notifies our (~20 classmate) review committee, by sending
to each the Production URL (USNA63.org) and an attached Evaluation Form
[currently being drafted by MAB; a simple feedback form which the three
of us can agree to.]
3] NStar makes the official request to USNAAA to link our production
site. [expect a few individuals to discover our site via this link
prior to:]
4] Announcement of Grand Opening: in NStar's July/August
Shipmate, plus e-mail sent to Class List on 7 July 1999. [and USNAAA
will make their own announcement for their new site in July as well]
Starting 7 July 1999, we are in our Standard Maintenance Mode.
Note 1: Definitions:
Standard Maintenance Mode:
unlimited changes made at development site by MAB;
MAB notifies NStar when he thinks a specified page
is ready for upgrade;
NStar corresponds with MAB until NStar likes what
he sees and is convinced we have an upgrade ready;
at that time, NStar requests WLK to move the
specified page from development to production site.
[see HostMaster notes on this process]
Development site: www.wlk.com/~usna63
Production site: www.USNA63.org
Validation period: 6 May 1999 - 6 July 1999
Grand Opening: 7 July 1999
MAB: webmaster
WLK: hostmaster (aka domainmaster)
NStar: Class Secretary
Note 2: During the Validation Period, MAB will continue making changes to the Development site; requests for upgrades to the Production Site will be kept at a minimum while reviewers are providing their comments (to keep the moving target to a minimum). Expect a request for upgrade one month before Grand Opening (on or about June 7, i.e., after about a month of Validation), and another upgrade request about a week before Grand Opening (on or about 28 June).
Note 3: WLK keeps the two sites up and operating; the Development site URL is known only to the select few [primarily NStar, WLK, MAB] so we can experiment with whatever we want out there. The world knows only what we have told them: www.USNA63.org is all that exists, as far as the world knows.
Note 4: [from WLK] I would prefer that NStar notify the webmaster who,
in turn, notifies WLK what
to migrate. The reason for this is that I'm anticipating that
approvals will
be made on conceptual/thematic collections of material whose composition
is
best known to the webmaster. The migration process is on a
component basis, so
I think it's better for MAB to notify WLK of the list of components
to migrate.
My chores are very mechanical in nature, but one of them is to undo
the simple
content organization favored by the Netscape Composer and spread it
across
subdirectory trees that are more easily managed from a computing point
of view.
This is how I tried to start it when I realized I was superimposing
computing
theory over the creative work. There are a lot of nerd reasons
to do it
"my way" that have nothing whatsoever to the composition or theme(s)
of the
material. That's why I enthusiastically support the notion of
developing and
approving on our private face and presenting from our public face.
Were we to
not periodically empty out the private bucket into the public cups,
it would
soon become cumbersome and unwieldy.
Let me suggest that we not worry about server resources for a while. The machine is loafing. Current utilization is 32 packets/second on three networks (512 is when I start noticing, 4096 is when I start groaning), average load 0.00, 0.00, 0.01 one second, one minute, and five minute respectively. We've swallowed 1% of the machine in the last five minutes, less than that more recently. My first eyebrow goes up at 100% one second utilization, the second at 400% one minute utilization. I'm not trying to impress anyone, I'm saying were a long way from any boundary conditions. I have not relocated any of the server's other duties, so there's margin even if we throw a hell of a burden at it.
WLK resources are something else. I think a searchable index
is a good thing. I want to extend that to include soundex.
That would enable us to produce Nstar's name if it was entered as
Shelly, Shellie, Shelli, or Skelly. These are programs I need
to write and make available for Blackie. I think I can stay
far enough ahead of him so that I don't slow him down. - BK
The database itself is little more than a pile of records made up of
data
fields. What makes it all work are the indices. An index
is nothing more
than a binary tree (read "blinding fast") of the data fields and their
associated record numbers. Some obvious index files are alphabetic
by
surname, alphabetic within company number, soundex. We can index
on anything
you can think of (that's why I'm boring you with the lesson).
Some will have
unique entries (surname within company unless there are duplicates),
others
will have intentional duplicates (soundex).
I envision that once we have these recorded and indexed the way we want
Blackie will produce his rosters from them using cgi routines.
This eliminates
the tedium of maintaining cumbersome html tables and enables the visitor
to
limit how much they want to see. If, for example, I want to see
only Co 4,
I don't have to get the entire Batt 1 to do it. Certainly Blackie
can
accomplish this with separate URLs, but if he cuts too fine there's
no easy
way, other than by duplication, to get a broader view and if he cuts
too coarse
there's no way to avoid a leviathan (sp?) download.
[Web Site Policy from Class.Secretary:] Note that under "Desirable Content" for the Web site was included: '3. Classmates' valor - Navy Cross (3) and DSC (1) citations, with Lucky Bag portraits.' Certainly we want to display the more important citations on the Valor page. It would be better to have a separate area for "other" decorations that are noteworthy but not uncommon. I wouldn't put them in anyone's Current Info area because that might look like bragging or something.
The bigger question is whether or not to include "other" decorations at all. I could argue both ways, but am inclined against including them. Legions of Merit are fairly common among the O-6's and above. Navy Commendation Medals (NCM's), NAM's, MUC's, etc. are way too numerous to display all in our Class. I think we should restrict our focus to combat-related decorations only, and then only Silver Stars and above, including Distinguished Flying Crosses (but NOT Air Medals), Legions of Merit with "V," and any significant foreign-conferred decorations. The only exception would be decorations for heroic acts in peacetime (e.g., Navy and Marine Corps Medal).
[HM comments:] HM agrees that the recognition that accompanies seniority isn't the same as valor. By that I do not intend to diminish the value of the contribution, but I do mean to distinguish it from heroism. HM also agrees with WM that lesser citations could be linked elsewhere to conserve bulk on the Valor page. I don't think it's disrespectful or inappropriate to "click for more". Some may want just the highlights, others may drill deeper.
Very short illustration... The gold star is used for second awards of some Navy decorations, but a bronze star (different size) is used for unspecified others. Silver stars signify the fifth award, but the one for five gold stars is different from the one for five bronze stars and the legends under the images make it clear they are different. There also appears to be one device for the second and only subsequent Air Medal but still another for the third and more. Sheesh! No wonder the SECNAV manual is 13MB and uniform regs 11MB.
The large (5/16") stars are placed on the ribbons for awards other than unit, campaign, and service awards except for the Navy E and Air Medal. Those use the smaller 3/16" stars except for the Navy E award. I forget what that one uses but the SECNAV manual spells it out. Uniform Regulations are less than helpful on these but I'd have figured it out.
I have made replace images for Mike Cronin with the
star for second award. I think the star is a bit large, but will
leave the determination up to you two. The images are the same size
as what Composer specifies for the oak leaf clustered images, the URLs
can be obtained from the following images:
| Silver Star second award medal: | |
the medal
found at URL: /awards/medals/tmed05star1.gif |
|
| Silver Star second award ribbon: | |
the ribbon
/awards/ribbons/rib05star1.gif |
Cronin's Legion of Merit citation explicitly states
that the use of the combat device is authorized, that means the combat
V. The SECNAV manual says that the citation must so state to authorize
its use on the several decorations to which it applies. I made Legion
of Merit medal and ribbon images for Cronin:
| Legion of Merit with Combat V medal: |  |
the medal width 54 height
109
found at URL:
|
| Legion of Merit with Combat V ribbon: |  |
the ribbon width 145 height 40
found at URL: /awards/ribbons/rib07v.gif |
Two suggestions regarding decorations:
1) If you think it beneficial for any reason, I will capture new images
of
each decoration we use and make them uniform in size.
Keeping ribbons
at 145x40 seems to look OK (check Whalen's to confirm
or deny), I'll have
to experiment with medals a little. The masters
are considerably larger
(and more grainy) so reducing them to a common geometry
actually helps.
2) If WM uses the production area images (.../jpg/mumble.jpg) he can
avoid
Composer's helpful insistance explicitly specifying the
geometry. That
has bitten my butt more than once when WM asked me to
make an inflight
repair. In other words, don't pull the image to
the Albuquerque surgical
suite and allow Composer to not try and "help".
That and the above said, let's recall that we were very much fledglings when we did this the first time around. We were so tickled to have such pretty things to show that we didn't pay much attention to uniform sizes and such. Further WM and HM were still struggling with how to negotiate a truce between Composer and the development vs production stuff. We didn't do badly, we did well, it just seems we did badly in retrospect. My ImageMagick skills have improved by several orders of magnitude and I'm hoping that WM will now trickle out some of those things he wanted but was afraid to ask :-) Note that I did Cronin's Silver Star and Legion of Merit ribbons and medals and Whalen's ribbons in less time than it took to gut out the one medal and ribbon with the cluster upside down... Gosh I feel stupid about that. Admittedly until I read the specification I didn't know. I'll murmur a defense that the cluster is upside down in the All Hands original.
Sources for Decorations
[From HM]: I hit the jackpot on images when I was trying to figure out how to tell you the URLs for the decoration precedence. First off the Silver Star is of lower precedence than the DSM (can and often non-combat award). I thought it was lower than the DFC, but it isn't. Here's the Army URL:
www.perscom.army.mil/TAGD/TIOH/ribbons.html
Navy isn't so concise but you can find it. The reason a conventional URL won't work is because BuPers/ChInfo have moved machines around and put some intercept URLs in place. Find the Navy equivalent as follows:
go to www.navy.mil and click on All Hands
at the All Hands home page click on the January issue of any year and when you see the table of contents, you'll see what you want.
Some sage advise from a 4MHz Z-80 computer relic. In those days
when we did something complex we started it and went and did something
else for a while. Apply the same principle when you click on the order
of precedence, USA or USN. It's gonna take a while. Click on
it and go make coffee while it loads. It's worth the wait.
I suggest we use colors to indicate which men died in the line of duty,
and
perhaps those who died in combat. What do you think?
My only concern about color is that it can introduce visual clutter.
We might
perfectly understand the conventions but it if isn't intuitively
obvious to
the visitor, it's confusing. Let's remember that www.usna63.org
is a public
place. Our visitors will include classmates, loved ones, and
complete
strangers. We don't have to adjust to the least common denominator,
but we
should adjust to the least intimate denominator. - BK
Screen Resolution [pixels per inch] and Monitor size. We are designing for HM's PC checking, which is done "with a laptop and lunchbox with 12" LCD displays at 1024x768. I have a 19" on a PC but it's a lab rat that's seldom powered up. My sister uses 1680x2048 and I can't see a thing on her screen even with my glasses. She stays with the 17" because she doesn't want a monitor she can't manhandle by herself." Meanwhile, Class.Secretary's monitor is set for 800 X 600 currently. He reports, "If I go to a higher res, the text on my 19-inch monitor is legible but uncomfortably small for my late 50's eyes."
Most monitors use 1024x768, HM's Sun is set at the default 1152x900
(really)!
HostMaster: Procedures for 1963 Web Site
For Nstar's benefit, since I brought him in late, Blackie and I were
doing
some pondering over what to put on the official site pending the approval
of
class leadership. He suggested tacking up an "under construction"
sign with
a link to the preliminary presentation. This also gives him a
working link
he can report back to the USNAAA. That's exactly what I did.
He further
suggested, I wholeheartedly agree, that he notify me when to move web
material
approved for the official site. I drag Nstar back into the loop
because
it answers two questions I posed regarding what to do now and how to
handle
things in the future. A proposed policy is enclosed.
I've been thinking about how you want to handle the "approved" web material
and I think it makes good
sense from every point of view I tried.
>From a strictly creative viewpoint you have complete freedom to do
as you
please in the ~usna63 "playpen", i.e. nothing new to learn. In
other words,
you concern yourself with content without regard to subdirectories,
file
naming convention or server plumbing.
>From a strictly technical viewpoint I can apply nerd technique to keep
the
official material from becoming unwieldy. Since the blunt instrument
(text
editing html) is my weapon of choice, I can fragment, subdivide, and
store
in what ever fashion makes computing sense while preserving your presentation.
>From a class leadership viewpoint the material all gets reviewed in
~usna63
and approved for presentation. You simply notify me what new
elements are
to be relocated to the official site. Jim would be in the approval
loop for
the Foundation materials.
The webmaster creates the presentations and notifies class leadership
when
they are ready for approval, revising as required. The hostmaster
will
provide any needed technical support, e.g. cgi scripts, programming,
etc.
The webmaster works at his own pace subject to any delays that might
be
introduced by the hostmaster working at his own pace.
Upon approval the webmaster notifies the hostmaster what presentation
elements have been approved for inclusion in the official web pages.
It
is the hostmaster's responsibility to ensure that each element functions
in exactly the same way it did when approved, but he has the technical
flexibility to computationally reorganize it to ease server administration.
For the record (but only for the record), the webmaster and hostmaster
work
under the supervision of the class secretary. In the (most unlikely)
event
of a dispute, the class secretary will arbitrate. I don't think
we need that,
but it would be stupid to not have it if we did.
I believe this meets each of the concerns expressed by each of us when
we
were worrying over policy and procedures. I've not addressed
how to handle
contributions (submissions) or suggestions because I think that should
be
the webmaster's discretion. I will create what ever computing
mechanisms
he may want or need to handle them. BK
If the item is a single htm file with some
related graphics, this would work. Many will be that simple,
but some will
not. When we get to searchable indices and related datasets,
we'll be dealing
with collections of material whose pieces and parts are better known
to the
webmaster, though approved as a concept/theme by class leadership.
As a practical matter, we shouldn't be too rigid about tweaks.
We omitted
a step that should be included in the process. WLK needs to notify
MAB and
NStar when he thinks he has successfully migrated the approved material.
That allows for a final sanity check to be sure that my reorganization
of the
material into a computing context didn't inadvertantly omit or destroy
some
vital component or relationship. This becomes more important
when the
content population is large, but it confirms that what got approved
gets
presented in the approved fashion. Tweaks are for typos, busted
links, etc.
that escaped everyones' gaze.
There's another nerd component regarding performance. We have
a prompt home
page startup because it's compact and transfers quickly. I also
have more
than one instance of the server listening for connections. This
saves the
time it takes to spawn and load a server to reply to the query.
I've only
got three instances in context right now with a high water mark of
ten. We
may find that there needs to be more in context simultaneously with
a higher
limit. There is plenty of memory (192MB) and CPU (two) to go
around, so we
should be alert for slow response situations. I am fairly attentive
to it,
but my access is via a 100Mbps LAN connection, so by the time something
seems
slow to me, it's unacceptable to the world. The web pages other
than USNA63
are recreational and get very little traffic, so their resource competition
is de minimus.
We may choose to password protect the development site if we find that we've attracted too many tourists. The actual access, getting and putting material, is already password protected, I mean protecting the top level index.html from being browsed without a password. A strong disclaimer might accomplish the same purpose.
The www.USNA63.org machine is a relatively secure system, moreso than the other server here that's visible to the Internet. I don't allow ftp (file transfer protocol) to it except on a case basis by address restriction and in each case I require password authentication. Both of you are using dialup connections to the Internet. That means you have a different IP address each time you connect. Tim Harvey has a cable modem with a fixed IP address. I have Tim's address hard wired into the "permit" list, NStar's not at all, and Blackie's as a network. There are 253 possible addresses Blackie might use and he has no control over which one he gets, so I enabled all 253. I don't like that, but it's the only way to get it to work the way we want. I rely on password protection to repel any access attempts from someone in the same address space. In other words I accept a vulnerability and rely on another mechanism to protect the information assets. I accept the risk because there is legitimate work that couldn't be done if I didn't.
FYI there are daily incremental backups locally and to the file server. I run full backups to tape when the incrementals get bulky or when it has been a week or ten days since I ran one. Even if we encountered a catastrophic failure we'd be no more than 24hrs, worst case, late for recovery. I mean if Blackie uploaded something and the disk melted down ten minutes later, he'd still have everything up to 00:05 that day. I have run the tripwires, so it's time to start the tapes. Tripwire is an anti-intrusion thing. I keep electronic signatures of anything someone might try to meddle or defeat. BK
This is presented as a proposed working agreement between SC and HM for the creation and maintenance of the locator maps. These things are a lot of painstaking work, several hours apiece by each SC (creation) and HM (appearance grooming). The CWM should be final QC.
The current creation sequence is that SC obtains the CWM mailing list, he has the roster with postal addresses, and he uses those, cut & paste into the html using predetermined X and Y coordinates for the pins, then he places the text. After he has it the way he wants it, he puts it on his personal web site and HM collects it with a Save As operation into Map??.html in pending.
HM then copies it to Map??.html in pending and begins the process of making the cosmetic compromises that are invisible to SC's Mac and HM's Sun. HM uses the Sun as control to make sure things don't get too far from their original location but stipulates that Map??.html _always_ looks worse on a Mac and a Sun than did the original Map??.html. If the Netscape transplant for wretch is successful, the Map??.html will be checked with it in addition to IE-5 that's in use already. When HM claims to be finished he will ask for a final sanity check from SC before notifying the CWM to inspect it and approval for relocation to the company home page.
The most irksome things for SC are organizing the postal and e-mail addresses. HM proposes to create two data files keyed by graduate number, one for postal and the other for e-mail addresses. It's entirely possible we have one but lack the other. Of course without the postal address we don't know where to put the pin unless we use the one in the roster marked as undeliverable. These two flat files will be input to a program that will write skeletal html in the form that SC currently uses. This will solve two problems. SC is working from a tab delimited file that makes for sometimes odd appearance and requires duplication of the TITLE= attribute that drives Internet Explorer and the ALT= attribute that drives Netscape. HM's travails yesterday with 03 says they can be identical space delimited quoted strings and can be generated such that they are easier for HM to work with in the text editor, Composer willing. This also eliminates typos or at least makes them consistent (we have at least one bad e-mail address).
SC and HM will work out the details of the format and content of the html skeleton and it will be tailored to lessen the labor required to produce and groom the maps.
We should probably add another link south of Texas that says to e-mail any changes to the CWM. If we want to eliminate that chore for the CWM, they can send them to HM since he has to keep the datasets up-to-date anyway. The rationale for going via the CWM is to give him an excuse to panhandle/nag for current data if there isn't any yet.
Significant changes should probably be done the way HM and SC have developed already. SC gloms a copy from pending (unpublished) or the home page and makes the changes putting them on his web site as Map??.html. Recall that HM makes significant changes to the X and Y coordinates for both pins and text, so SC has to inherit that to apply his changes. HM gloms a copy from SC's web site and repeats the creation process but needs to only work on SC's changes.
HM has stared until crosseyed at what more automated assistance can be applied, but can not write a program that can see. So much of this is visual, the only practical help is clerical and the skeletal html will go a long way to minimizing that grunt work. There's some grunt work that can only be done by a high level grunt and in this case the eyes have it. BK
MailServers/Forwarding from site:
NStar@USNA63.org
forwards to: NStar@citcom.net
Blackled@USNA63.org forwards to:
Mike@Blackledge.com
Here are the aliases I have established thus far, others can be added
at
will without heartburn. I suggest you update the html to use
them.
Class.Secretary@USNA63.org
forwards to: NStar@citcom.net
webmaster@usna63.org
forwards to: Bill@wlk.com
WebMaster@USNA63.org
forwards to: Mike@Blackledge.com
Blackie/WebMaster@USNA63.org forwards to:
Mike@Blackledge.com
Added on Christmas Eve 1999:
Proctors@USNA63.org forwards to: Class.Secretary/HostMaster/WebMaster@USNA63.org
Here are some of the 'vanity plates', now for Company Webmasters, some originally for ELB Aces:
WebMaster: Parameters for 1963 Web Site
We strive for consistency across the site, knowing that our visitors
may view different looks using different hardward/software combination.
This, from the HostMaster:
"Different look? I get different looks on Suns with 8 and
24 bit displays. I get different
looks on the laptop with IE5 and the PC with Netscape 4.51. I
get yet another
look on the DEC Alpha with Netscape 3.05. When I say 'different'
I mean fonts,
colors, page arrangements, you name it. "
Nevertheless, it benefits us to maintain some standards, such as:
Classmate Rosters:
Table text: 12
pt Verdana
Shipmate Columns:
Secretary's text: 14
pt Times New Roman
Contributor's text: 12
pt Comic Sans, indented
Classmates, living: Craig
Thrasher
Classmates, deceased:Carl
Doughtie
Note: this color coding of classmates will be used throughout
the site; however, when a name is linked [indicated by underlining] the
color code cannot be maintained.
Current Bios:
The following is the style/page layout template
as of 24 Dec 1999 for header: classmate current information, leading to
the text:
Classmate Lucky Bag Photos:
When HM designates a URL with "graduate" he means
the graduate number, not the character string "graduate". Thus a
full size photo for Graduate # 314360 would be found at:
http://www.USNA63.org/classmates/roster/old-photo/314360.jpg
of size HEIGHT=240 WIDTH=190. The miniature is:
http://www.USNA63.org/classmates/roster/old-photo/M314360.jpg
of size HEIGHT=96 WIDTH=76.
When received from Class.Secretary, Classmate death notices will be inserted as a hot news item ASAP. They will be removed when the next Shipmate (which will include this news) apppears on the site. This can become SOP for death notices.
Webmaster will consider information from Class.Secretary as an 'official' death notice [unlike Tom Haney's, where we have no written documentation], and so will add Classmate's name to Last Call page, add his Obituary to the Obit page, linked to obit from Last Call, and will also link to obit from Class Roster [two places; once in Company, and once in Class/Alpha roster]. Also, Webmaster should add year [e.g., "1999"] to death date, as we need that year in Obit, although usually inferred in Shipmate.
The obit will become the 'current data' for the deceased; an example URL for the line in Last Call is:
http://www.USNA63.org/classmates/roster/cur-bio/322180.html
I agree that we don't want to maintain the static rosters, and eventually [I said 2000] we want to delete the graduate static roster. However, I would like to maintain indefinitely the non-grad static roster, as an easy way to obtain the full name of the non-grad. [Grads have full name in ELB] - I want to use the full name in Last Call and Obits, and this is an easy on-line reference, without requesting HM, CS, or WM to go back to the Excel [or whatever] USNAAA database for non-grads and pull up the full name.
I suggest as policy:
If a policy amendment is in order, these appear to be the sequence and accountability:
o CS learns of the death and confirms it
o CS notifies WM and HM of the death and any accompanying data
he may have
including newspaper obituary or an assignment for
someone to obtain it
for WM
o HM borders the ELB photos, updates the master roster, and
notifies WM of
the URL for the photo. HM does nothing else
unless specifically directed
by CS or WM. The URL for the photo contains
the USNAAA graduate number
o WM prepares the deceased data page, uploads it to the development
area, and
notifies HM of the URL and link into Last Call.
WM will use the .html
extension on the document to keep it from appearing
in the POD change list
o HM amends the document for technical conformance and appends
the navigation
bar before relocating it to cur-bio/graduate#.html,
then creates or
modifies the cur-bio/graduate#.bio to cause the
display to be visible on
the ELB page
o Should updates become available or errors need to be corrected,
at WM
discretion, he either collects the document from
the site and repeats the
two prior steps or tells HM what to change in place.
In either case WM
will notify HM whether or not to backdate the updated
document to avoid
its appearance in the POD change list
This may not be a bad process for future columns: CS sends Shipmate column text to WM (as in a Microsoft Word column), who prepares it and loads it as an HTML file, perhaps with [empty] tables as placeholders for photos to be placed, and then uploads HTML version of Shipmate column file to site; CS concurrently sends photos to HM, who resizes and economizes and crops to perfection. Meanwhile, WM works on Shipmate Index, and any targets needed in the column. Finally, HM integrates the photos into the column, and voila! we've got it!
[CS:] === Yeah, that'll work. Let's go with it for the September 2000 issue a month from now.
[HM:] [during September 2000 issue processing] === I propose we do it this way: WM composes the document and uploads it to the development area, notifying HM so that he can promptly relocate it to the production area pending. HM then applies the images and notifies WM and CS of the URL. When approved, HM relocates it to the public area and we're done. These relocations are each a single command line thing lest either of you think there's any effort or inconvenience with this. For the Sep00 column some of the cropped images aren't sufficiently more compact than the original to justify using them. A good example is [Sept 00 photo #] 04. I removed the flag to focus on the people. I left the flag in another one, but CS might prefer leaving the flag in 04.
Question to CS: Shipmate was, just a few issues ago, limiting the columns by size, counting each photo as many words. Your current column seems to be well beyond early limits - have they dropped that policy?
[CS:] === The nominal limit is 4,000 words. Photos of three or
fewer people are counted as 150 words; 4 or more count as 250. The
Shipmate staff has been somewhat flexible in the past, sometimes printing
the group photos larger than I had anticipated, sometimes not. It
is all a matter of how they can get the Class News layout to work best.
My word count this month was ca. 2,600 words. Ten photos at 150 words
each would bring the total to 4,100 words. I suspect that's close
enough. If the Shipmate folks should get picky, I'd drop the Ortwein
item and run it next month. You'll be the first to know if I have
to chop anything.
We have a marvelous site, we're proud of it and so is
the rest of '63. We get compliments from numerous and various sources,
all earned and deserved. As I scrolled through our policy page, reading
every word, it became very clear that our enjoyable and successful experiment
is not unlike the evolution of our republic. Some intelligent men
blessed with vision assembled and composed a blueprint and *followed* it.
Amendments were made as necessary but they were debated until the best
compromise could be reached. The fits and starts were inevitable,
few, and handled within the concepts of the founding blueprint. I'm
not going to get maudlin, but I must state what may not be obvious to either
of you. I've been on a lot of teams where the other players were
smarter or stronger than I was. I've had the recommended daily allowance
of defeat, sometimes in overdose amounts. This is the first effort
in which I have been engaged where each principal hauled their share of
the water without departure from the founding principles.
| This page is
Policy & Procedures last updated: 29 July 2000 |
Navigate to:
|
 |
 |
 |
 |
