Accordions let users click on content to reveal additional content associated with that item.
In a nutshell, if you’re uncertain, don’t use them. Basically, you’re always safe not using an accordion. However, there are various traps in using them.
Here’s a list of Pros and Cons about them and where you should and shouldn’t use them.
- creates a mini table of contents
- you have to click on each heading to access more content
When to use them:
- when the sub items of your content are exclusive – e.g. someone will only want to click on one item. An example, being a list of conferences
When not to use them:
- when the user may want to open the majority of the items
- if the user may want to copy and paste the entire content
If you do decide to use one, a key rule is – do not auto close them. If a user wants to copy multiple items of content you’ve just created a major usability problem.
See also: http://www.nngroup.com/articles/accordions-complex-content/
Quick, visual explanation of what trackbacks and pingbacks are. Note that website and blog can be used interchangeably here.
1. Someone (Person A) writes a Post on their website (A)
2. You (Person B) read it and want to comment on it. BUT you want your readers to see your comment AND comment about it on your own website (B). So, you post on your own website (B)
3. Now, you send a message to website A (this message is called a trackback) which contains an excerpt of the comment you’ve posted on your own website
4. Their website (A), having received your trackback, now posts your comment to their post which links back to your website
1. THEIR WEBSITE (A)
2. YOUR WEBSITE (B) THEIR WEBSITE (A)
YOUR POST --------- LINKS TO ----------> THEIR POST
3. YOUR WEBSITE (B) -- SENDS A TRACKBACK --> THEIR WEBSITE (A)
4. YOUR WEBSITE (B) THEIR WEBSITE (A)
YOUR POST <------- TRACKBACK LINK ------- YOUR COMMENT
The only difference between trackbacks and pingbacks is:
- trackbacks use HTTP POSTs
- pingbacks use XML-RPC
Think of pingbacks as remote comments.
ARC supposedly does away with reference counting. However, blocks introduce a small wrinkle.
When you reference self in a block you make a strong reference to it which encourages leaks as you end up with objects (including View Controllers) hanging around beyond when they’re needed.
The solution is to define a weak reference before the block and use that. Inside the block you convert it to a strong reference. We don’t have a proper strong reference outside the block so it decrements as it should do. However, it’s a pain (see the first part of the linked-to post).
This is where the @weakify(self) technique makes things simple and easy. See the second part of this post!