Feature request: Metadata

[markhalliwell]

I know you probably have other things to worry about so this isn't a huge priority. It would be awesome if we could have the ability to specify an additional "Title" for each icon. This would give those of us who do things with the config.json file the ability to print out a more "human readable" value in say, something like a dropdown menu. Perhaps it would default to just being empty.

[puzrin]

Imho, that will be step to wrong direction. Because human readable texts should be translateable. It's better to be done in other place. Because that will add not universal thing, which will not be used by majority of people.

But, i'm still open to suggestion. Fontello was done without keeping in mind, that you can do something with config.json. If you could generalase such ideas - you are welcome.

For example, you could do request "add field to enter glyph metadata", with examples, what can be done with it.

[markhalliwell]

Um, actually that's exactly why I want it to be in Fontello in the first place. The raw title should be in the config.json file and then translated by whatever is parsing it. For instance:

    {
      "search": [
        "plus"
      ],
      "code": 43,
      "from": 43,
      "uid": "44e04715aecbca7f266a17d5a7863c68",
      "css": "plus",
      "orig_css": "plus",
      "orig_code": 43,
      "src": "fontawesome",
      "title": "Add"
    },

I'd parse this icon's title property and run it through Drupal's t() function: http://api.drupal.org/api/drupal/includes!bootstrap.inc/function/t/7

[puzrin]

1. title will duplicate css or orig_css. Use one of it for t.
2. Every icon can have multiple meaning. So, it's impossible to to make title, that will be universal and correct.

[markhalliwell]

1. title is not duplicating css or orig_css... these are class (machine) names for the icon. A title is a human readable representation.
2. I'm not asking for you to put in the titles, in fact you should leave title blank by default. The end user (people like me) would have to manually go into the names tab and configure the titles themselves if they wanted them. So yes, they can have multiple meanings, which I (the end user) would know and want.

[puzrin]

Human readable texts must be in translation system. t needs readable tag on unput. Why not use css field for it? Could you explain, why do you like to keep your custom english translations on fontello? That looks specific and not universal.

[markhalliwell]

And that translation system is the CMS I am using, not Fontello.

This function http://api.drupal.org/api/drupal/includes!bootstrap.inc/function/t/7

Takes English strings and translates them into other languages via language packs that are downloadable through

http://localize.drupal.org/translate

Typos courtesy of Siri

On Apr 28, 2013, at 1:23 AM, Vitaly Puzrin notifications@github.com wrote:

Human readable texts must be in translation system. t needs readable tag on unput. Why not use css field for it? Could you explain, why do you like to keep your custom english translations on fontello? That looks specific and not universal.

— Reply to this email directly or view it on GitHub.

[puzrin]

Ok, i think, problem is in naming. title kills my brain by lack of flexibility. As i told, it's possible to make metadata field, where you can keep anything you wish. Text, json, multistring and other, depending on your implementation.

[markhalliwell]

I just don't like the idea that other stuff could be put in for something that would be used as a display title. Meaning that, if on Fontello you label the text field "metadata", it isn't intuitive that is what is going to be mapped to "title" in my app.

Typos courtesy of Siri

On Apr 28, 2013, at 1:41 AM, Vitaly Puzrin notifications@github.com wrote:

Ok, i think, problem is in naming. title kills my brain by lack of flexibility. As i told, it's possible to make metadata field, where you can keep anything you wish. Text, json, multistring and other, depending on your implementation.

— Reply to this email directly or view it on GitHub.

[puzrin]

But title can confuse other people, who don't use it, or like to use metadata in other way. For example, one can add there colors and other things. Fontello should not be nailed to one specific solution.

[markhalliwell]

And that is an excellent suggestion. Perhaps there should be an additional metadata field. I can see use cases for metadata in my app too, but that should be separate from a title which would be used in an administrative user interface.

Typos courtesy of Siri

On Apr 28, 2013, at 2:32 AM, Vitaly Puzrin notifications@github.com wrote:

But title can confuse other people, who don't use it, or like to use metadata in other way. For example, one can add there colors and other things. Fontello should not be nailed to one specific solution.

— Reply to this email directly or view it on GitHub.

[puzrin]

Yeah... and then another developper will cry, that metadata confuse his users about colors :) . It's impossible to guess all types of use, and i don't like idea to add multiple fields in advance. IMHO, right now metadata allows to implement all technicas issues. But things about usability should be done only after massive users feedback.

Possible use:

title=My title
color=#ddd

[markhalliwell]

Fair enough. Believe me I understand how feature creep can be frustrating.

Another possible solution would be to allow dynamic fields to be created and any fields created would have a key and value. Then in the icon JSON data we could something like:

meta: { title: "My title", color: "#ddd" }

Typos courtesy of Siri

On Apr 28, 2013, at 2:54 AM, Vitaly Puzrin notifications@github.com wrote:

Yeah... and then another developper will cry, that metadata confuse his users about colors :) . It's impossible to guess all types of use, and i don't like idea to add multiple fields in advance. IMHO, right now metadata allows to implement all technicas issues. But things about usability should be done only after massive users feedback.

Possible use:

title=My title color=#ddd — Reply to this email directly or view it on GitHub.

[puzrin]

That's possible, but right now looks like overengeneering. I still need to keep good ratio for (added value) / (spended time). To summarise our talk, i plan to add:

• one universal field
• help text for that field

Exact name/texts are discussable, but result should be flexible. That field will be added in glyphs data editor, that will appear soon. Since we stabilised nodeca core, fontello updates become more frequent.

[markhalliwell]

That's acceptable for now. Lets keep this open so others can comment. We can revisit complexity/simplicity later lol

Typos courtesy of Siri

On Apr 28, 2013, at 3:14 AM, Vitaly Puzrin notifications@github.com wrote:

That's possible, but right now looks like overengeneering. I still need to keep good ratio for (added value) / (spended time). To summarise our talk, i plan to add:

one universal field help text for that field Exact name/texts are discussable, but result should be flexible. That field will be added in glyphs data editor, that will appear soon. Since we stabilised nodeca core, fontello updates become more frequent.

— Reply to this email directly or view it on GitHub.

[puzrin]

Hi Mark. Fontello now has properties editor for custom icons (preliminary draft). I'd like to discuss metadata feature with you again.

The first and the main question - do you still think, that it's really needed :) ? I think, you could get feedback from users of your wordpress plugin. May be, your vision has changed. Do you have clear understanding, what really useful can be done via metadata? Probably, all is already ok as is :)

Need your opinion on current moment.

[markhalliwell]

Yes, I think that having meta data would still be nice. https://github.com/fontello/fontello/issues/154#issuecomment-17130359 is what I was originally wanting. This would allow us to start human readable titles for icons in the package (ie: icon-pencil's title could be "Edit Document" or something). I could then modify my Drupal module to check each icon to see if there's "title" meta data to use say... in the drop down select box.

[puzrin]

Nobody prohibit you to save metadata on your side, and then assign it back by glyph ids after getting archive. Probably, i don't understand what do you suggest. Try to explain again for stupids, with details (or mocks) of the whole process.

I don't refuse to extend interesing features, but need clear understaiding. Because i have no time for multiple rewrites :)

[puzrin]

@markcarver are you alive :) ?

[markhalliwell]

Yes, just been a little busy lately focusing on other things. I'm not sure how else I can describe this, but I'll give it a shot.

I don't disagree that I could indeed save the meta data (ie: human readable title of the icon) on my side. I just think that it would be beneficial to associate that data with the icon itself (ie: inside the JSON file). This would allow the meta data to be importable in the future as well as sharable between other (hypothetical) services.

Plus saving this information on my side means that I would have to create a DB table of some kind to keep track of all this meta data and associate each icon with it's counterpart information. This also means I would have to keep track of which icons were deleted/added and update this meta data appropriately. I just makes sense to keep all of this information together in one file, a file that Fontello provides.

[puzrin]

This would allow the meta data to be importable in the future as well as sharable between other (hypothetical) services.

According to my experience, it's a bad practice to spend efforts in advance for something hypothetical. Because you have to spend efforts right now, and hopotetical things will not happen. It it will change 100 times, and you efforts will be trashed, because will not fit new requirements.

Plus saving this information on my side means that I would have to create a DB table of some kind to keep track of all this meta data and associate each icon with it's counterpart information. This also means I would have to keep track of which icons were deleted/added and update this meta data appropriately. I just makes sense to keep all of this information together in one file, a file that Fontello provides.

I don't like to do all that things with tables too, LOL. Joke.

Honestly, i'm not shure, that you will manage to keep integrity with assosiated data. Because you will need to fill altername names for all 2000+ glyphs. That's next to impossible. Or may be i don't understand your suggestion.

IMHO, the best way to check is to write detailed user behavior, step-by-step. For example:

1. User open plugin admin page
2. ... do something ... (what?)
3. Go to fontello site
4. Select glyphs (where to take metadata for new glyphs)
5. Returns back to admin (how metadata processed and glyphs mapped)

For each step you should have a clear understanding:

• where is input data taken from
• who is responsible for data processing, and how data is processed
• where output data goes to

I don't try to burst your brain, that's a usual software design process for non trivial cases. If you can do such description, that will be a proof, that idea will not fuckup in the middle of implementation. And that will greately help me to understand, what should be done at my side. Also, probably, i could point some logical mistakes or more optimal implementations.

I still remember, that you suggested #134, that growed into API. And don't think that you ask useless things. But i still don't have the the whole plan in my head, how metadata should work. Could you prepare detailed "behaviour" description? That's not completely trivial, but much faster that coding without good plan :) . If i can help with it in some way - let me know.

[markhalliwell]

[markhalliwell]

Also, I get that I could change the name of the icon to "favorites" but this also isn't really what I'd like since it should have a capital "F". Ultimately this is about separating the machine name (class) of the icon and a presentable human readable "title/label" for the icon.

[puzrin]

If i understand you right;

• you need to define 'human readabe name'
• you don't care about css name at all

How about this solution:

1. You will send config requiest with empty icons-prefix.
2. I will remove limits on CSS names content, but urlEncode non-ascii chars. That will allow to enter any text
3. When user returns back, you will extract human-readable texts from glyph.name, and will generate CSS names/files automatically. As far as i understant, users don't need to have access for CSS names directly, in your case.

That requires almost zero change in fontello, and will not confize people with strange additional editable fields.

[markhalliwell]

No. I don't want to use glyph.name (which is the css class name) for the title/label at all. I want to be able to have both, with different values:

{
  "name": "heart",
  "title": "Favorite"
}

[puzrin]

I plan to change name editor to something like this http://vitalets.github.io/x-editable/demo-bs3.html . It will allow to add second field without problems.Setting field label to "title" via config param is not a problem too.

But why don't you wish to completely visually "remove" name field, and leave title only? That could make interface more simple.

[markhalliwell]

Because I have legacy JS code that relies on the machine/class name of the icon to remain constant. This would allow the front end title to be dynamic and editable, without breaking existing code.

[puzrin]

Ok. That will be done. How soon do you need this feature?

I plan some code/interface rework, to significantly improve speed and to better handle growing icons/fonts count. Your request can be implemented somewhere in that process without additional efforts. Since that's all done as background task with low priority, that will take 2-3 months. Is it ok?

[markhalliwell]

Yeah, no rush. Like I said, I've been a little busy focusing on other things at the moment. No rush, but will definitely eventually need this just so clients understand what some of these icons are for.