FamilySearch Wiki:FamilySearch Beta Skin IssuesEdit This Page
From FamilySearch Wiki
- A list of actionable items with examples:*
- [CLOSED] TOC sub-topics are not indented and there is an extra space after the parent topic.
- [CLOSED] TOC and Info box are not side-by-side at the top of content pages. (.
- [CLOSED] (Code) Right-hand navigation missing from the home page. (FYI: Search for or navigate to any page in the wiki and you get the navigation back.) () ([COMM-528|https://fch.ldschurch.org/jira/browse/COMM-528])
- [CLOSED] (Content) Search for article you want to create. The option to create the new page is gone ()
- [CLOSED] (Code) Table lines are not showing. (Help:Tables) ()
- 8/2/2010: CODED, but questioning solution. David to converse with Grant on better solution. David to report in Tues AM standup. Need solution by 9:00 am Tues.
- 8/3/2010: Solution: Make a copy of Frankie's reset style sheet, and remove table border reset. Some hard coded table sizes can now be replaced with the style instead of being hard coded.
- [CLOSED] (Content) Code examples formats are not showing. (, 
- [WAITING FOR NEW PORTAL PAGE DESIGN] Parts of maps being covered by right-side tool bar. The right-side bar is covering several pages whether it's maps, images or tables. (Tennessee) ([COMM-530|https://fch.ldschurch.org/jira/browse/COMM-530])
- NOTE: There are two major pieces to this issue.
- Tables are bleeding into the right navigation. Solution is to change the font size of the tables. This will be done week of 8/2
- We will work with Mark M. to come up with a design for portal pages to move the left column down below to move the images, such as the Tennessee map over to the left. This will be done week of 8/9. (Please be careful about the proposed design plan. States like California would push the content of the page way down. Even the Utah map would cause the same problem. Is there any way to change the design plan to just giving back the content space that was there before by reducing the size of the navigation boxes on the right? \-Fran)
- Also we will create a style guide to be placed into the "guiding principles" under the community section of the right nav. (I believe you mean the Manual of Style, not the Guiding Principles? \-Fran)
- NOTE: There are two major pieces to this issue.
- [CANT DUPLICATE] Using the rich editor is showing the blue skin so it's confusing to see the blue skin when editing, then save and see it in the FS Beta skin. (Riverton_FamilySearch_Library)
- Comment by Nate:
- I haven't been able to duplicate this issue. I'll see if I can get more info, or have someone else try duplicating.
- Comment by Diane: this is the most obvious when you are working with pages with tables on them. Try any of the state census pages. Or look at Template:RAOGKcourthouse and edit it in the FCK editor.
- Comment by Nate:
- [WAITING FOR STYLE GUIDE--David to drive] Tables that have been coded by the users to be right justified appear to be being forced to the left. Also, justification within the cells of a table are also being forced to the left. This displays the tables slightly different in Firefox and IE Example: Random Acts of Genealogical Kindness template used on many pages one of which is Anderson_County,_Tennessee and Template:RAOGKcourthouse Also, the images in the table of the US and the flag at the top of the Tennessee page are supposed to be centered in the cells, but they keep going left. Tennessee not a big deal here, but a big deal in other places. (We need to be careful about the example pages that are being documented in this backlog list. The users are fixing the pages faster than we can fix the bugs. So when you go to a page that was supposed to be an example for one the bugs, you may find that the page now looks right. See the Tennessee page for example - the images have been rearranged on the page and now all three appear at the top. So now we don't see the image map being cut off on the right and we flag at the top of the page is not forced to the left. Now all three images are at the top and it's look very nice. I sent an email to the user to made the changes telling them that I liked what they did with the page. \-Fran)
- [NEEDS DESIGN- David driving] Visited links colors not changed. (Crow_Indians) ([COMM-536|https://fch.ldschurch.org/jira/browse/COMM-536])
- There is still a question in the UX team about whether or not to have visited links change color.
- [CLOSED] Images that were coded to be right justified, now appear on the left. (Tennessee_Newspapers) ([COMM-537|https://fch.ldschurch.org/jira/browse/COMM-537])
- [CLOSED] \*** Headings aren't as prominent as in the original version. ([COMM-538|https://fch.ldschurch.org/jira/browse/COMM-538]) \[The community has mentioned in forum threads and discussions that headings 2 & 3 look exactly alike in size, color, font. \-Fran\]
- [CLOSED] Delete link is not a button anymore. (https://wiki.familysearch.org/en/index.php?title=User:JensenFA/Testing_delete&action=delete) ([COMM-539|https://fch.ldschurch.org/jira/browse/COMM-539])
- [NEED EXAMPLE--waiting for Fran] \**\* Back-links, bread-crumbs are not working. (The example from the community was posted in the JIRA ticket.) ([COMM-540|https://fch.ldschurch.org/jira/browse/COMM-540])
- [CLOSED] \*** The table of contents the \[Hide\] link is flushed right. When you hide it the \[Show\] link is flushed left. (Denmark) ([COMM-541|https://fch.ldschurch.org/jira/browse/COMM-541]). Something has been changed in the wiki to change the behavior of the \[Hide\] link. Now the link appears on the next line below the word "Contents" - this is just as much problem and maybe even more so. With the link on the next line below, it's hard to tell what the \[Hide\] link is for. Plus it pushes the content down one line. If there are tables or images or other content surrounding the table of contents, it will sometimes push the content out of sync with the page. I saw this today on the community tech meeting agenda page. \-Fran)
- [CLOSED] \*** Large images are covering the editable sections of a page. (Marion_County,_Tennessee) ([COMM-542|https://fch.ldschurch.org/jira/browse/COMM-542])
- This issue doesn't seem to only be related to images. It's also affecting the way the Riverton Library is formatted. Riverton_FamilySearch_Library \- the Riverton page is currently being redesigned, so you may not see the problem on that page anymore. I will add other examples as I come across them. \-Fran - I like the new look of the Riverton FamilySearch Library page much better. \-David C.
- [NOT PART OF WIKI SKIN UPDATE, but committed to SVN] Polling Widget. David added code to blue skin that shows article with name A on right side bar with given name, if article with name B, show up on bottom.
- Poll content was never delivered. This will be completed in Sprint 32. \[Note that this item is not a bug, but instead it's a feature. Shouldn't enhancements be on a different backlog? \-Fran\]
- [CLOSED] \***** External links are missing the arrow icon. (Help:Tables) ([COMM-543|https://fch.ldschurch.org/jira/browse/COMM-543])
- [CLOSED] \****\* Type in sidebar search box. Then click the magnifying glass icon. Search is not executed. (Denmark) ([COMM-544|https://fch.ldschurch.org/jira/browse/COMM-544])
- [WAITING FOR NEW PORTAL PAGE DESIGN--David driving] \***** Navigation bar too wide and taking up valuable content space. (New_York_Censusand Alabama_Census) ([COMM-545|https://fch.ldschurch.org/jira/browse/COMM-545]) \[If this item was fixed first, then several other bugs on this list would likely be fixed at the same time. For example, items 8, 10, 16, 17, 23 (when you go to the history page...), and 27 (Image file pages have a problem...) might all be fixed by returning the available content area to the same width that it had before. \-Fran\]
- [NEEDS DESIGN--Nate will drive] Display name vs. Username? - \[I believe iItems 22, 24 (when the user clicks on ...) , and 25 (related to the sign in bug...) are the same bug - Fran\]
- Issues related to Username vs. Display name in the header, in the Personal Tools menu, and in articles. What name should show where and how should the wiki preference affect this? Should there still be a preference in the wiki that affects this?
- [CLOSED] When you go to the History of a page, the two columns of radio buttons for comparing different versions are too close together. (David already mentioned the content area was narrower than before and that this change was causing a lot of other issues. The radio buttons is another example of the same issue)
- [WORK AROUND--WILL NOT FIX right now] \****\* When the user clicks on the "Sign in" link at the top of the Frankie screen, the result is the FS standard sign in name appears. But when the user navigates to the Wiki, their sign-in name does not appear under the Personal tools (Mediawiki standard) navigation title. Instead, only the IP address shows after sign in. If the user chooses to click on the "Sign in" link that appears in the Wiki's Personal tools, the Wiki's username appears, but the Frankie screen in the top right corner still says "Sign in". Possible bug in the fssessionid. The users name does not show up at the top of the screen as logged in.showthread.php?t=3242
- Frankie header sign-in problem. You have to refresh the browser once after signing in. Right now the fix is that we have not removed the wiki Sign In link in the Personal Tools navigation box.
- [NEEDS DESIGN, Part of 22] Related to the sign-in bug is the difference between the sign in name and the preferred Display name in the wiki. The wiki preferences allow the user to choose a different display name in all wiki contributions instead of using the sign in name. For instance, my sign in name is JensenFA and all the pages that I add content to or comments on Talk pages are attributed to the user named "Fran" in the wiki. DSammy reported in the forums that his sign in name and display name preference was not working.
- [CLOSED] On every page in the wiki there is an associated "Talk" page. When the Talk page has never had any content added to the page, the link to it has always been red. In the current design, the "Talk" page link is always black, even when the page has never had content saved on the page. Example page: FamilySearch_Wiki:Technical_Meeting_Agenda_27_July_2010
- [NEEDS DESIGN, BUT FILE HISTORY TABLE IS FIXED] Image file pages have a problem with content being cut off on the right side of the screen. Here's a copy of the description I added to the forum that includes two examples: The auto-generation table that appears on all image file pages is cut off on the right. Only about half of the last column in the table that shows the history of the uploaded image appears. Some images are larger than the viewable area, causing the image to bleed into the navigation on the right. See and as examples.
- [CANNOT FIX WITH STYLE CHANGES--same as in blue skin] When in edit mode, there is an option to disable the rich editor. When the user clicks on the preview button, the rich editor returns and the user has to click on the option to remove it again. This bug can be seen on any page in the wiki after you click on the link to edit the page. \[Fran added this item, so see her if you have questions.\]
- [WILL NOT FIX--same as in blue skin] Headings 1 and 2 lock the content bars to full width of the content area and results in forcing other content either above or below the heading. This design prevents the editor from adding images, tables, maps, info boxes, and other items to a section that would easily span content between the two headings. \[Fran is creating the template for society pages right now and cannot use the right headings for the different areas of content because of this issue. There are other pages in the wiki where this item can be seen, but I'll have to go searching for them.\]
- User comments (from forums):*
lembley \-\- As one of the less-technical users, I think I am uniquely qualified to plead that you not give less-technical users more power than they have knowledge enough to use. Placing such significant emphasis on "Create a New Page" will likely result in many, many irrelevant pages being created because users aren't simultaneously being coached into how to find if an article already exists to which they might contribute. There are already many overlapping and/or redundant articles. Stronger emphasis should be placed (visually) on contributing to/editing existing articles, not starting new ones.
jbparker \-\- I can tell you from experience that the new "washed out" look will NOT be popular with older users nor with people with eyesight problems. While I was an editor of a magazine, our art department came up with a new "artsy" look with less contrast, more color over color printing, and many other artistic changes. We had a MAJOR negative reaction and had to go back to a cleaner, more easily read look. Please be sensitive to that feeling.
Charlene Pipkin \-\- Please consider rewording this box (Make a contribution). \- I agree that the word "contribution" might be interpreted as a solicitation for money. "Add information" might be a better phrase. \- It says "contribute new articles or edit an existing page" but "Create a New Page" is the only button and it doesn't cover editing an existing page. \- "Tell us about where you grew up or live now" can be interpreted 2 ways. My first reaction was that this was intrusive--that's too personal. Then I realized that it's meant as a springboard for ideas for expanding content. Perhaps it would be better to omit this phrase.
G Fröberg Morris \-\- My biggest concern is how much screen real estate was lost. Can we narrow the blank color stripe around each page?
- This page was last modified on 15 August 2014, at 02:07.
- This page has been accessed 255 times.
Share Your Opinion!
Review redesigns of wiki pages and give your feedbackImprove the Wiki