Fields for each speaker would be Name, bio, CSS ID, and photo URL.
The CSS ID is so that we can link to the speaker's bio from the program page. All or most of the speakers that are up on the site now currently have them. It would be great if you could make the CSS ID automatically be the speaker's last name. I almost asked you to do this but was concerned that there would be some kind of conflict of two people with the same name, or weird issues from people who have two last names or special characters in their last name. If you know a good way around this, then go for it! I think it's fine as long as there is clear documentation I can reference about the way it chooses the CSS ID in unusual circumstances.
One idea comes to mind that would solve all the problems I can think of, which is that it automatically generates the CSS ID, unless you write something in the source markdown document like FORCE_ID: and then manually set one.
For all the fields except Name and CSS ID, we also need a way to mark that the field is empty and have it show up gracefully in the generator. I think the keyword NULL would be good. See the next item below this for more of my thoughts on it.
The first few speakers in the source markdown file will be keynotes, which as you know are formatted slightly differently. It would be good for the generator to understand this, and automatically format them differently if they are under the first n-level heading rather than the second.
Fields for each speaker would be Name, bio, CSS ID, and photo URL.
The CSS ID is so that we can link to the speaker's bio from the program page. All or most of the speakers that are up on the site now currently have them. It would be great if you could make the CSS ID automatically be the speaker's last name. I almost asked you to do this but was concerned that there would be some kind of conflict of two people with the same name, or weird issues from people who have two last names or special characters in their last name. If you know a good way around this, then go for it! I think it's fine as long as there is clear documentation I can reference about the way it chooses the CSS ID in unusual circumstances.
One idea comes to mind that would solve all the problems I can think of, which is that it automatically generates the CSS ID, unless you write something in the source markdown document like FORCE_ID: and then manually set one.
For all the fields except Name and CSS ID, we also need a way to mark that the field is empty and have it show up gracefully in the generator. I think the keyword NULL would be good. See the next item below this for more of my thoughts on it.
The first few speakers in the source markdown file will be keynotes, which as you know are formatted slightly differently. It would be good for the generator to understand this, and automatically format them differently if they are under the first n-level heading rather than the second.
Fields for each speaker would be Name, bio, CSS ID, and photo URL.
The CSS ID is so that we can link to the speaker's bio from the program page. All or most of the speakers that are up on the site now currently have them. It would be great if you could make the CSS ID automatically be the speaker's last name. I almost asked you to do this but was concerned that there would be some kind of conflict of two people with the same name, or weird issues from people who have two last names or special characters in their last name. If you know a good way around this, then go for it! I think it's fine as long as there is clear documentation I can reference about the way it chooses the CSS ID in unusual circumstances.
One idea comes to mind that would solve all the problems I can think of, which is that it automatically generates the CSS ID, unless you write something in the source markdown document like FORCE_ID: and then manually set one.
For all the fields except Name and CSS ID, we also need a way to mark that the field is empty and have it show up gracefully in the generator. I think the keyword NULL would be good. See the next item below this for more of my thoughts on it.
The first few speakers in the source markdown file will be keynotes, which as you know are formatted slightly differently. It would be good for the generator to understand this, and automatically format them differently if they are under the first n-level heading rather than the second.
LP speaker template is ready. See https://pypi.python.org/pypi/lpschedule-generator more info.
Closing this issue.