jpavley / emojiworkshop Goto Github PK

Allow user to select all or some groups and subgroups to narrow her search.

The search text is:
The search text is: Bug
== scrollViewWillBeginDragging()
== scrollViewWillBeginDragging()
== scrollViewWillBeginDragging()
== scrollViewWillBeginDragging()
== scrollViewWillBeginDragging()
== scrollViewWillBeginDragging()
== scrollViewWillBeginDragging()
== scrollViewWillBeginDragging()
The search text is: Bug

So that “woman” returns both “woman” and “woman,”

W3C Emoji group, subgroup, and descriptions are just not enough!

Doesn’t seem to be implemented by iOS 11

But the ID (Priority property) under the

Use .startswith instead of contains

Browse

• Header: filter button, count label, search button
• Default state

Filter

• Body: table view with checkmarks for each group and subgroup
• Header: cancel button, count label, done button
• Animation: pops up, covering main table from button

Search

• Search field, cancel button
• open animation: expands right from search button (on left)

• Test coverage 100%
• Unit, Integration, and Mutation Testing
• Red-Green Refactoring
• Functions no more than 4 lines long
• Discover all embedded classes (functions)

“”

should return facepalming

Feed the emoji images into Apple's machine learning engine and use it to generate new text metadata. Emoji descriptions are often metaphorical and not descriptive. Person Frowning is a yellow woman with blond hair and a purple shirt. Seaching "woman" or "yellow" will not find her.

Available but nobody seems to use them--not even apple!

Clean up tags and turn them into buttons

• Stem and de-dupe
• Transform into buttons
• Design default table view so the ID# is under the Emoji and the tags have more room and are bigger.

detective hat with thinking face... maybe? just an idea

Emoji Detective?
Emoji Inspector?
Emoji Agent?
Emoji Spy?
Emoji Explorer?

Makes blood type Emoji unfindable.

Uncle Bob says a function should be 1 to 4 lines long. And For loops and If clauses should contain only on line. And for loops should be transformed into map, filter, or reduce functions. Code should be dry and not wet (Don't repeat yourself).

• Renumber from 0.
• Don't use ID internally as it's really a position in the test file which will change over time. Instead use the value of the emoji itself.

• Default: Table view.
• Swipe Left: zoomed out view with just clickable emojis organized into clickable categories. Touching an emoji goes to its detail view. Touching a category filters to just that category in table view.
• Swipe Right: Detail views in long table.
• Shake the phone to restore to the default view with no filtering

While there are over 50 categories of emoji they are both too specific and too general--and there are too many of them! Example: Smileys & People: face-fantasy is just 11 emoji. It it leaves out many other fantasy emoji (anthropomorphic grinning cat faces, genies, baby angels, Mr. and Mrs. Claus, mages, etc..) There are 125 emoji tagged fantasy and searching for fantasy yields much better results than browsing by category.

But searching by fantasy or other tags with a large number of emoji would benefit by dynamic scoping of search results. Fantasy could be broken down into faces, people, yellow and all.

The scoping bar doesn't have space for more than a few terms and all needs to be the first term. Plus I don't want to manually create scopes for each search results (as that would be impossible!)

So a good toy algorithm might be:

• if the search results are over a screenful (6-10) emoji then calculate possible scope terms
• if scope terms are more then 2 then dynamically display scope bar with calculated terms
• Scope terms are calculated by looking at popular tags. In the fantasy example there are 11 faces, 114 people, 114 persons, and large numbers of skin, tone, man, woman, etc... Tag groups would be have to be ranked by popularity and filtered by overlap (people and persons return the same results, skin and tone return the same results). The top 2-5 tag groups (depending on label length) would then be displayed in order of popularity as scope terms (with all always the first term).
• Scope terms would have to live with search results and should not be recalculated unless the list of emoji tags changes (say with user generated tagging).
• Term calculation needs to be super fast so the app can will respond instantly. Perhaps dynamic scoping is a feature of hitting the search button and not incremental results while typing.

if the search term is "sport" then the suggestions include fencing, person, horse, racing, smileys, ... etc in the order of most frequent.

(key: "person", value: 1507)
(key: "smileys", value: 1507)
(key: "tone", value: 1060)
(key: "skin", value: 1060)
(key: "medium", value: 642)
(key: "light", value: 446)
(key: "dark", value: 424)
(key: "man", value: 386)
(key: "woman", value: 379)
(key: "role", value: 362)
(key: "flag", value: 271)
(key: "sport", value: 261)
(key: "country", value: 257)
(key: "body", value: 212)
(key: "place", value: 211)
(key: "travel", value: 207)
(key: "symbols", value: 205)
(key: "", value: 200)
(key: "gesture", value: 168)
(key: "object", value: 162)