Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mcefan

Pages: 1 2 [3] 4 5 6
Users / Re: Linux MCE beating as the heart of whole house automation
« on: October 01, 2012, 05:57:48 pm »
Feel free to forward the quote to me, and I shall take a look.
Thank you for your help.
Here is the quote:

No      Unit         MATERIAL                                                       EPG Price            
            1ST FLOOR                                                                     
      29      LITON LHLD615C70-DHL (LED RECSSED HOUSING)               
      29      LITON LRLD621W (LED RECESSED TRIM)                                                   
      4      LITON LPE330-48"-BLUE (PENDANT LIGHT FOR ISLAND IN KITCHEN)                                                                     
            2ND FLOOR                                                                     
      20      LITON LHLD615C70-DHL (LED RECESSED HOUSING)                                                                     
      20      LITON LRLD621W (LED RECESSED TRIM)                                                                     
      1      LOT PRICE FOR LIGHT FIXTURES                           $9,547.52             $9,547.52
      1      LOT PRICE FOR LIGHTING CONTROLS                         $6,500.00             $6,500.00
            CONSISTING OF THE FOLLOWING:                                                                     
            8 KEY PADS                                                                     
            18 CIRCUIT 0-10V DIMMING CAPABILITY                                                                     
            IP INTERFACE 9COMPATIBLE TO CONNECT TO PC                                                      TOTAL   $16,047.52             $16,047.52
            AND FACTORY START UP FEE                                                                      

Users / Re: Workgroup Wiki/Manual
« on: October 01, 2012, 05:17:05 pm »
But how do you educate people?

We need to try to communicate our methods upfront.
Write a page that will give orientation like the one here:

Maybe make it impossible for them to make a general catagory so they are forced to make an subcategory?

I don't know if that's possible.
We need to educate people, I don't know any other way.

Also, we need to stay on top of it on a daily basis and clean up. That's a job for administrators (they know the subjects and where things should belong).

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing
« on: October 01, 2012, 05:06:01 pm »
So where do you want to start?
I already started. I'm not for discussing things at infinitum. The rubber has to meet the road somewhere, and people have been complaining for too long. Whatever I can do while I'm reading, I will do, keeping in line with the decisions that have been made in the discussions (whenever they exist).
The problem I have is that I've just been around 2 weeks, so I do not know
enough yet. All I know is that learning has been extremely difficult, and that's highly abnormal for me because I learn fast ad read a lot. So I just decided to do something about the problem.
I actually started before even knowing that others were at it, because I could not even find that. I keep stumbling on things here and there in a disorganized fashion (lots of reading, good note taking, and luck). As I find things, I place them where they could easily be found, so others can contribute (at first, I thought it was not possible - that needs to be fixed). It was not CLEAR from the initial contact in the environment (something to remedy).

That said, I started with the ability to find things because that seems to be the biggest hurtle. Cosmetics matter, but "substance you can not find" is a game stopper. The most important thing for me at this time is the structure of the categories (the table of contents of the site). I did my best to read all previous discussions and comments I could find, and summarized them on my  user page. Please take a look.
twodogs 's suggestion needs to be implemented (,11910.msg83542.html#msg83542) along with purps' suggestion (,11910.msg83767.html#msg83767). This is desperate, we need to start something. Adjusting later will just be a matter of recategorizing a few articles (which should be an ongoing task anyway).
Right now, we need to be able to find things if they exist, and group them. At least, if they're not relevant to the user, they are all grouped and he/she can move on to the next one. That's not to say that they should not be flagged as suggested.
The categorization is crucial, and people must clearly see their options (other articles related to the same thing).

So, to answer your question: grouping the articles (categories).

The existing instructions are here:
We need to edit them.

What is the best approach?

Finalize twodogs 's suggestion (,11910.msg83542.html#msg83542) and start moving the articles. Each person can be assigned articles starting within an alphabetical range (for example: I could take care of F-J).
Please read the page I wrote about Article categories (, it explains how to position them in the list.
Also read the classification worksheet for some ideas of how to chose the labels of the categories:

Once they are grouped, we can assign people to standardize the content, each person being in charge of a section of a top level category.

Wiki / Re: Task | Identify structure of wiki | reqruiting / assessing
« on: October 01, 2012, 07:02:28 am »
Lets pretend that I insisted that the Homerun should go under TV, and you insisted that it appear under NAS We could put it in both places, just as current wiki articles can be set up to appear in "tutorials" and "hardware". But I suggest we avoid duplication if possible. ... If we have a 3-level structure, and if the index is always present at the left of the screen, then it is almost impossible to get lost.

There is a reason why shopping sites keep track of what you click on and make suggestions on what you should look at next, or what other people did following what you just did: thinking flows by association.
An article should be in as may categories at necessary.

If I just completed my install, it's just natural for me to wonder "what else" I should install before leaving the installation phase. - how do we get those sexy little arrows in the side bar like that?
By installing the extension. Please note that extensions are version specific.

Somewhere on the front page of the wiki, we should have a link called "Wiki Tutorial - Adding and Administering Content"

- In the "Adding Content" subheading, we would provide detailed instructions on how to create the perfect wiki article. We would have a link to the template everyone should use. We would give the authors the benefit of the doubt that they followed the rules, so there would be no holding area - a submitted article would immediately go up on the site.

- In the "Administering Content" subheading, we would have a table showing who is responsible for administering each major wiki chapter. Their first job would be move existing relevant articles into their chapter of the wiki. Administrators would periodically look at their wiki chapters for new content to make sure people are following the rules. If they found a problem they could fix it on the spot, get the author to fix it, or remove the article. If a particular chapter seems incomplete, an energetic administrator could go to the forums and request articles.

I added a few pages that that address some of the above needs. Please see the section title "Ongoing" on my user page:

I do like the user identified when it comes to seeing if a particular page works. That way I can track the user down for more info if needed.

Make the "discussion" tab of a page the standard communication medium for pages maybe?

To assist the work group and allow them to keep an eye on the wiki pages, can a daily summary of updated pages be emailed to the people that are maintaining that group of pages with a list of pages that need a review?

That is the function of the "recent changes" special page:
It can be filtered, but it's still labor intensive though, not automated.

Wiki / Re: Wikiworkgroup | Main topic
« on: October 01, 2012, 06:30:48 am »
I am not sure it is easily possible to have the sub-headings displayed dynamically.
It's possible. There's an extension for that. You can drill down right from the menu. It's dynamically built from the existing categories. The categories ARE the structural components of the wiki.
It does not have to be in the sidebar, it can be a separate page. Very necessary though, I would not have a wiki without it. It's easier to dynamically drill than navigate by opening several pages. It's also faster, and more comprehensive.

I am a gatherer. I much prefer to KEEP tags that we have, and add to them instead of removing existing tags and replace them with something else. The more links one has the better it is imho.
The problem with this is that the categories are the structure, so, we HAVE to recategorize as suggested,11909.msg85208.html#msg85208

However, the categorization has to be exhaustive for each article. Each article must be tagged with all relevant categories.

Lets pretend that I insisted that the Homerun should go under TV, and you insisted that it appear under NAS We could put it in both places, just as current wiki articles can be set up to appear in "tutorials" and "hardware". But I suggest we avoid duplication if possible. ... If we have a 3-level structure, and if the index is always present at the left of the screen, then it is almost impossible to get lost.

There is a reason why shopping sites keep track of what you click on and make suggestions on what you should look at next, or what other people did following what you just did: thinking flows by association.
An article should be in as may categories at necessary.

If I just completed my install, it's just natural for me to wonder "what else" I should install before leaving the installation phase.

Users / Re: Workgroup Wiki/Manual
« on: October 01, 2012, 05:52:32 am »
Topology comes from the mixture of 2 words: topos (place) ans logos (word/explanation/intelligence). It's about how it came to look the way it does (like landscaping), the reason things look the way they do.

So, the question could be rephrased as: are you trying to create a logical tree of the subjects covered in all existing pages?
If bongowongo meant something else, he/she can clarify (what i explained is the meaning the sentence carries).

The link proposed above links to all special pages, that will not give you what you are looking for.

I realized that people need some help with the actual use of the wiki software, so I wrote a couple of articles. Please read the articles linked on my user page. Look at the section titled "ongoing", and read the articles on categories. You will find a link in it that will give you access to the structure you are looking for in the section "How to display the index of the existing categories".
Just so you know, there was no predefined structure, so all the categories end up forming a flat structure instead of a tree.
Categories are the equivalent of folders. They should be hierarchical.

What needs to happen now:
  • create a list of top categories
  • create some subcategories
  • recategorize pages by placing them in the subcategories

The top of the tree should not change if it's comprehensive when created.
Also, no page should be placed in a category. The proper place should be a subcategory. That way, categories will automatically create the structure you are looking for, and enable people to drill down subject matters.

If there is no clearly predefined structure, we can not expect people to place their writings in the proper place. We need a page instructing people on how to pick the right categories, rather than merely telling them to categorize. It's simply not enough.

Wiki / Re: Started a Glossary page on the Wiki
« on: October 01, 2012, 04:47:30 am »
One particular thing would be to include horizontal and vertical dimensions of the various TV resolutions. ...
Anyway, that's my idea...
Were you able to do it?

Wiki / Re: New LinuxMCE Documentation
« on: October 01, 2012, 03:32:15 am »
Finding presupposes knowledge: knowledge of the location of what you are looking for.
To find it, you have to look for it where it is.

I created the following article to help with the thinking process:

Wiki / Re: New LinuxMCE Documentation
« on: September 30, 2012, 10:08:03 pm »
Our wiki is about as unfriendly as it can be. Want to know how to set up a RAID? Go to tutorials, but don't expect it to be under "R" - its under "C" for "Create RAID". Want to learn about PXE boot? Don't look at "P" - its under "G" fro "GRUB PXE network boot"

Well, it looks like you have a good handle on this problem. Why not rename the pages when you encounter that? You can do that by using the "move" tab on top of the page, and rename the article.

Which brings us to naming conventions.
When naming articles, as much as possible, start with a noun. This should be obtained from answering the question "what/who is it about"?
Once the subject matter is properly identified, we need to specify the action or characteristic at addressed in the article.

what/who is it about: booting
action or characteristic: from network - PXE
resulting title: booting from network - PXE

This will keep all boot related articles within proximity:

booting locally
booting remotely
booting from network
booting from network - PXE

It makes it easier to place the articles in the right categories afterwards (when necessary).
The key is to identify the subject accurately.

Wiki / Re: New LinuxMCE Documentation
« on: September 30, 2012, 09:51:54 pm »
whenever I go to the wiki, I don't browse, I search. So searching for PXE and/or RAID does return the right information.
There are several ways people acquire information.
People do not intuitively "search" when they get on a site. Instead, they "browse".
Information should be acquired in a progressive manner. Since you "own" the information, people expect you to lead them. Besides, when starting from scratch, how could you expect me to know what to search for? You post assumes I now what PXE is! What's that?
Also, even if I pull the right pages from an excellent search (assumes I got lucky typing the right terminology and the articles actually use the same words), what tells me that I am looking at the right information, and not missing something? I can search if I know: searches are based on pre-existing knowledge. Incomplete, but never the less, pre-existing.

Have you noted this from twodogs:
I often find it easier to find wiki articles from a Google search "LinuxMCE black screen" or whatever. Good info on a particular piece of hardware might be found by looking at the main page of the wiki under "Hardware", but maybe the info is in "Tutorials/Guides" or the "User Manual", or the FAQ, or maybe its floating around in the wiki at large.
The frustrated user then asks a question in the forums, where a frustrated Thom complains (rightly so) that he has answered that question a thousand times.
When people have to navigate away from your site and use google to find what's on the very site they are on, I'd say you have a problem: searches don't work. They don't, because things are not organized. You can not find info in a folder by searching another...

If you want a larger user base, you can not make any assumption. All blanks, including the "obvious" ones, must be filled. The best documentations are the ones that cover all user levels, from ignorant to creator.

Navigation is vital to a site. Most people get frustrated and quickly quit when there is no logical progression to follow, or when things are not simple, or when things are difficult to find. The reason why frequently accessed pages are included in shortcut menus is to give the most common starting points. People explore, and tend to take note of the related elements, and explore those also. That's why you make things available by sight.

I suggest some reading on the subject of information architecture, it will help the venture.

What about my requests?

Wiki / Re: New LinuxMCE Documentation
« on: September 30, 2012, 08:34:41 am »
I am having problems putting things in place and I do not want to duplicate content.
Please install the following extension: ASAP so I can continue. I'm stuck on many pages.
Also, see about changing my access level at least for 30 days so I can help in the categorization. Too many pages will not enable to add the categories. I can't save the pages.

Thank you!

Wiki / Re: New LinuxMCE Documentation
« on: September 30, 2012, 08:06:18 am »
Found previous discussion on the topic at,11910.0.html and,11924.0.html
I will integrate these concerns in the list.

There needs to be a person in charge of verifying content added. Even if no one actually read all the articles, there needs to be a way for users to notify us of errors in documentation.
Who do people contact if they follow a procedure and find out it does not work?

To avoid having to duplicate information and create unreasonably numerous links, we really need section transclusion extensions. With that, we can create general articles from which we can select sections to include in several others articles without having to rewrite them. It will also help in keeping consistency.
There is no way to keep it clean with too many duplications.

The issue of version can be resolved by adding version categories to each page: [[category:0810]] [[category:general]] [[category:...]]
and making these categories subcategories of [[category:versions]].
This will give people the ability to navigate by drilling relevant versions.

Wiki / Re: New LinuxMCE Documentation
« on: September 30, 2012, 07:44:26 am »
Created a new "Add a page to the wiki" and "Help:Hyperlinks".
There is enough information now to enable people to edit the pages properly.

Wiki / Re: New LinuxMCE Documentation
« on: September 30, 2012, 03:50:06 am »
The talk page of the above document has a few requests:

There are many problems with the site.

1) It has been written in terrible English -- misspelled words abound and proper grammar is nearly non-existent. For example, "survailance" should be "surveillance". (A simple dictionary goes a long way.)

2) Only a small portion of the program is actually documented.

3) The changes in the program are not documented and "legacy" instructions are left on the page.

4) There is a lot of "fluff" in the documentation that is meaningless. You can't write "the program can do this and this and this!!!" when only one person has ever been able to do it. Hyperbole misleads the users.

Still, the Wiki is evolving in the right direction, slowly.

It the intent is to correct the main page, then you should get some help from the contributors to the Wiki.

I worked documenting code for an American defense contractor -- the problems with LinuxMCE documentation are not unique. Most programmers are terrible at documentation.

If you want good documentation, you must have a dedicated documenter and one programmer to whom the documenter can ask questions.

I integrated it to the list on my user page.

Wiki / Re: New LinuxMCE Documentation
« on: September 30, 2012, 02:19:07 am »
There is an old 2010 proposal called "LinuxMCE.Org 2.0" here:

Suggestions are:

The purpose of the new site is to provide a friendly, approachable face for LinuxMCE to new users. It must:

    - Provide links to understandable descriptions of the software
    - Present a user-friendly image of the site
    - Present a pleasing aesthetic to augment the above two requirements
    - Provide project news that affects users
    - Provide a way to easily download the software
    - Provide entry to the Forums
    - Provide entry to the Wiki for detailed documentation

Menu Structure (and links to the copy pages)
    - News
    - About
    - Documentation
    - Forum
    - Download
    - Contact Us

Proposed Color Scheme
   - Text: #000000
   - Highlight: #123456

I integrated it to the list on my user page.

Pages: 1 2 [3] 4 5 6