Profile Formatting

+4 votes
475 views

I like lists a lot! I’ve been using them for decades to improve clarity. Yes, before WT.

But I’m having some trouble with formatting. For example, WT Help says, “ In wiki markup, one line break (i.e. clicking Enter/Return) will be ignored. The line will wrap in the output. If you need to create a single line break, enter <br> at the end of the line.” But wherever I enter return, even here, I get a hard line break l don’t want. My issue is in open profile Littrell-533. I get an unwanted line break between my list heading and bulleted list elements. Go ahead and look, suggestions on how to tuck the elements under the header welcome - even if you’re politely telling me I’m clueless.

/s/jr

WikiTree profile: Bob Littrell
in WikiTree Help by Jerry Regan G2G6 (9.8k points)
Instead of using a url as a source, the entire citation should be entered since urls can disappear and they give no information as to what it relates to. It looks like you have some full citations at the bottom, but some don't have the url included, so they cannot all be connected.

Linda,

Good morning cuz.

I understand your position but respectfully disagree. With the full text of my sources in the bio’s raw form, it would double the length. I’m not big on a lot of scrolling while editing. It’s confusing and intimidating. I copied all my footnote URLs from the original FS citations  shown as sources (and apparently cut the link from the 1910 citation.) I’m relatively new at this and haven’t decided whether I like my sources inline or not. There’s pros and cons.

I do thank you for your comment. I wouldn’t have noticed I chopped up my citations without it.
Fixed.
/s/jr

Glad you rechecked the citations to make sure they had the urls. You have the marriage sourcexat the bottom, but you don't mention his marriage info at the top, which would be good to do along with his spouse.
Linda,

Whole profile is a work in progress. In the bio, I don’t say anything except when he was born. The marriage citation is for the marriage/spousal form at the top.

In some respects these three profiles are a rabbit hole. With the death of the son, it’s the end of the line. I have a number of brick walls that are far more important and interesting.

/s/jr

4 Answers

+9 votes
Unfortunately that is how the lists work. There is always a blank line inserted before the list. You can remove the <br/> since it is not doing anything in this case. The newline character is not doing a "Hard return" it is the * that starts a bulleted list that causes the spacing above it.

You could experiment with tables or other types of list but I think you will always have a space before it like that. A table would allow you to keep the heading closer to the rows
by Rob Pavey G2G6 Pilot (197k points)
BTW you don't need to use <br/> in most cases. Generally a paragraph break is done using two newline characters.

So rather than:

Robert was born about 1907. <br/>
Residences:<br/>
* 1910 Fort Wayne Ward 9, Allen, Indiana, United States

You can do:

Robert was born about 1907.

Residences:
* 1910 Fort Wayne Ward 9, Allen, Indiana, United States
Here is an example of using a table:

{| border="1" cellpadding="4"
|- bgcolor=#e1f0b4
| Date || Residence
|-
| 1930 || Lebanon, Boone, Indiana, United States
|-
| 1940 || Chicago, Cook, Illinois, United States
|}
Ron, I’m really sorry to see your answer. It was what I feared. Not your problem, of course.

I’d read in other answers that a table could work but they could be fragile. I like KISS.

As for the </br>? There’s a place for white space, but too much leads to a broken span of attention and lots of scrolling. Using the </br> cuts down on scrolling while editing.

As I said, while I can’t say I am happy with your response, it’s what I expected and the way tings work. Thanks for your time.

/s/jr
What you could try is a colon followed by an asterisk, as such a structure seems part of wiki markup for lists.  See how it looks, anyway.

:Residences:
:* 1910 Fort Wayne Ward 9, Allen, Indiana, United States<ref>https://familysearch.org/ark:/61903/1:1:MKLY-35S</ref>
:* 1920.Elkhart Ward 2, Elkhart, Indiana, United States<ref>https://familysearch.org/ark:/61903/3:1:33S7-9R6X-JBJ?jcc=1488411&wc=QZJP-V6G%3A1036470701%2C1037386301%2C1037429801%2C1589332341</ref>
:* 1930 Lebanon, Boone, Indiana, United States<ref>https://www.familysearch.org/ark:/61903/1:1:X415-XK9</ref>
:* 1935 Same Place<ref>Typically a State census, however, Indiana did not perform a statewide survey in 1935.</ref>
:* 1940 Chicago, Cook, Illinois, United States<ref>https://www.familysearch.org/ark:/61903/1:1:KWY8-916</ref>
:* 1950 Oak Lawn, Cook, Illinois, United States<ref>https://familysearch.org/ark:/61903/1:1:6X18-B8JG</ref>
Hmmmm…

Tried colons but not :Residences:

Worth a shot

/s/jr
The :* approach would avoid the spacing between "Residences" and the first item in the list. But it will indent both. So the "Residences" line will be indented compared to the line above.

I sounds like you are trying to fight the system. WikiTree pages have a certain CSS style - i.e. how much space is before and after a heading and how much space is before a list. It seems like you are trying to avoid the standard style by manipulating the content.

If you would prefer a different CSS style when you are viewing a profile (rather than changing the style for everyone else) then this could be achieved via an extension. E.g.: the new official WikiTree Browser extension could have a "compact" style option that would reduce a lot of the spacing. If you had this option enabled everything would be closer together and more would fit on your screen.
YES! I can live with Melanie’s suggestion.

But I still want a fix. I learned in my time in Support that a workaround is not a fix.

/s/jr
Rob,

I’ve tried the colons and the results are satisfactory. I’d rather not have the list separated from the rest of the text but in my view it’s better than separating list elements from the heading.

Your suggestion for a browser extension is, IMHO, a workaround, not a fix and only works if the viewer has the extension. Unacceptable.

In my experience, I haven’t seen too many ‘documents’ where there’s a line break between the heading and the list. A break above the heading and one below the last line, maybe. Whitespace breaks the flow of a document. In typewriter days the double space between paragraphs signaled a new thought. List formats allowed easy reading because the alternative is a,b,c,d and e. When those elements become long, like a URL, lists became big, black blobs, unreadable, so the style allowed list elements to be presented on individual lines terminated by semicolon exact for the last two in the form “d; and <br/>e.”

Let’s not talk about CSS style. That’s a tool. What does the CoM have to say about presentation of lists?

I really don’t care if I’m breaking established CSS style. Many of my lists need to flow with the surrounding text. The current rules prevent that. It’s almost as though the desired bio format is either simple text or blocks of bullet points. \/\/

/s/jr

The colon/asterisk combination was used on a profile I saw, for listing the wife and children.
As it is wikitext / wiki markup, not html / css, it is allowed under the styles and standards -- and is MUCH easier for collaboration purposes than a table might be.

The only other way I could think of would be to use &#8226; to create an unlisted bullet at the beginning of a line, and the <br /> at the end.
Doing the above would have the benefit of no whitespace between the "list" and the text before and after.

+2 votes
What you would have to do to get the desired effect is place a line break < br > at the end of the line followed by a number of hard spaces, followed by the bullet character.
by Tommy Buch G2G Astronaut (1.9m points)
I can't see how this would work.  For a list the asterisk or the hash mark needs to be flush against the left margin.
By using a  <br />, then (a) space/s, then the asterisk, you would just get an asterisk, not a bullet point.
I said type the bullet character:  •

I didn't say type the asterisk:  *
So, &#8226; ?

I have never had any success using alt etc.  Hence the &#8226; for a non-asterisk bullet. 
Posts in g2g allow for selecting the • from the "insert special character" menu, so I suppose it could be copied from that and then pasted (because I would never find the right page in bookmarks - as I have saved similar pages dozens of times because I couldn't find earlier saves  cheeky).

Tommy,

That might work on physical keyboards where there’s always a Cmd, Cntrl, or Shift key. But on iPads, those keys are not always on the virtual keyboard (ABC, 123, etc refers to symbol on key used to switch to a keyboard layout.)

* ABC keyboard has Shift, no Cmd nor Cntrl;

* 123 keyboard has no Shift, nor Cmd nor Cntrl; and

* #+= keyboard has no Shift nor Cmd nor Cntrl.

On my iPad,I have issues typing an apostrophe, as in isn’t, can’t or O’Regan. In the typewriter days what looked like an apostrophe was also a single quote. At least WT seems to think it’s a single quote when I try to search for O’Regan. Apple gave me the same answer as your link. Then told me to buy a $200 physical keyboard as a workaround - they called it a solution.

Happy Holidays!/s/jr

Using what are known as "smart   quotes" (single or double) will cause technical issues.  

Only straight ' " quotes work properly.

Melanie,

G’day! The only times I’ve had problems is with putting an apostrophe in O’Regan (typed from keyboard) or similar names.  I’m certain the key is a smart single quote - it leans right at the top.  ‘X’ sure looks like those quotes are smart. The problem: Using my virtual keyboard on my iPad, how do I enter straight quotes/apostrophe? WT wants O'Regan (cut/pasted from a profile page) but as seen above, I can’t enter that.

Happy Holidays!

/s/jr

'X'. O'Regan. Whoooooraaaaaay!

It looks like a simple switch _does_ change keyboard behavior. That other question with an entry that said turn off smart punctuation was right!

Really Happy Holidays!

/s/jr
+4 votes
Hi Jerry,

Two things I noticed on the page.

You have a Footnotes heading. Footnotes are sources that appear at the bottom of each page of printed material.  WikiTree doesn't support Footnotes when printed so you should remove that heading and just let the sources fall under the section heading of Sources.

Also, sources you cite should be above the "See also:" section.  Sources you don't cite should be under the "See also:" section.
by Tommy Buch G2G Astronaut (1.9m points)
In addition to what Tommy says about the footnotes header, it has been placed between the Sources header and the <references /> "tag".  Styles and standards require that the references "tag" be placed immediately beneath the Sources header, with nothing between.  (It was not always that way, so some older profiles may still show otherwise.)

== Sources ==
<references />

With such a layout, don't be surprised if sometime a Data Doctor (or more than one) pays a visit to such profiles to correct the errors in layout.  (They mean no harm, but such corrections can cause other problems with non-standard layouts.)
I’ve been playing. I really don’t like the look. It just took me awhile to fix it.

/s/jr
All,

Perhaps I should describe my logic for all this.

I believe the format for the raw text is at least as important as the format for this displayed text. Why? Because it minimizes errors in future maintenance. A bio, that upon opening for editing looks like a huge black blob will result in errors. I know because when I added my simple ref tags i frequently had to go back for repairs. Imagine how that black blob would look with the full citation in there. As I’ve pointed out before, it would have doubled the size of the biography section, leading to more chances for mistakes.

I also do most of my work on an 11 inch tablet. White space is important for legibility but too much pushes information off the screen . I pity those who might try to use WT with a mobile phone!

Not knowing, I have to ask, how much consideration was given to tablets and standalone laptops (no external monitor) when policies and design issues were discussed? IMHO, laptops used for WT need a medium to large external monitor.

It’s common for popular websites to have two versions, one for ‘regular’ devices and one for ‘mobile’ devices. I am not suggesting WT go there, but the internet has seen substantial change from its DARPA days. If I recall correctly, terminals were dialup TTY devices.

I’ve ranted long enough. My point is that I have practical as well as aesthetic reasons for my editing choices, reasons that challenge, “We’ve always done it that way”.

/s/jr
+2 votes
The blank line which appears under the headings (whether followed by a bulleted list or plain text) has always been there.  Sorry.
by Ros Haywood G2G Astronaut (1.9m points)
With all due respect, “We’ve always done it that way,” is an excuse that has never been a legitimate reason— for anything. I think it’s fair to say that progress has only been made in the world when that excuse has been ignored/dismissed and another way has been found. IMHO.

/s/jr
Actually, I didn't say "We've always done it that way".  I said that that was the way it has been for years, not that a mythical 'we' had chosen it to be that way.  There's probably a technical reason why it's like that.  Add the tag 'jamie' to your question and maybe she can explain why it's that way.

Oh, and because you seem to prefer to hear from people who know what they are talking about, Jamie Nelson is a Team Member and is in charge of bug fixes and improvements.
Rod,

I agree, you didn’t say,”We’ve always done it that way.” But with all due respect, take a step back and tell me that’s not the message. The impression I got (perhaps not what you intended) was a brush off, that my question was not worth consideration.

What would your response have been if I had assumed the break was intentional and made a change request?

/s/jr
There was a discussion in another thread about formatting. As I remember the discussion WT uses a 3rd party software package. WT technical team can't make changes to this. We users have to use it as is. Changes would only happen if the authors make the changes. It was implemented to make formatting easier (that native HTML). Sorry I can't remember what the name of the software.
Dave,

if what you say is true - I have no reason to doubt you - that, followed by Melanie’s suggested workaround, would have been the best first answer. Hard to fix or change what you don’t own. I’ve been there myself when working in support roles. It’s frustrating.

What, IMHO, is not acceptable is trying to push the problem back on the folks who report it. Support folks need to treat their products like children. A certain amount of protectiveness is required. But honesty is still required. If you can’t change things because you don’t own them, most folks will understand. After all, one can be sued for fixing something that doesn’t belong to them. I’ll concede not happily, but? \/\/

The wiki platform used by Wikitree is old and no longer supported - and has been heavily modified by WT.  That's why changes are difficult to implement, and seldom done unless thoroughly tested for potential bugs or other odd and unwanted behaviour.[citation needed]
That's also why many requested changes are now being applied by way of the WT extension (or by other extensions or apps).  The problem with this, as already noted elsewhere, is that such "improvements" are only seen if one has the app or extension, and that is unlikely to be the case for the casual dropping by on a whim visitor.

It is a fact that wikitext headers have following line breaks.  It is also a fact that wikitext lists also have those following line breaks.  The only way to avoid them with lists is to not use a list format.

Related questions

+8 votes
2 answers
478 views asked Oct 23, 2022 in WikiTree Tech by Francesca Murphy G2G6 Mach 5 (58.4k points)
+21 votes
1 answer
460 views asked May 6, 2016 in WikiTree Tech by Julie Ricketts G2G6 Pilot (481k points)
+7 votes
0 answers
185 views asked Mar 18, 2023 in WikiTree Help by Nancy Caton G2G2 (2.4k points)
+8 votes
4 answers
+5 votes
2 answers
344 views asked Jul 31, 2022 in Policy and Style by Andrew Sansum G2G5 (5.6k points)

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...