cocoapods / cocoapods.org Goto Github PK

This is due to the logic in here not working in this repo correctly.

I've struggled to have the shared_include function include context about the current page but I think that's the way it should be done.

The suggested dependency locks the minor version:

pod 'AFNetworking', '~> 2.2.0'

This is not desirable because, according to SemVer, the minor version should be backwards compatible. Therefore it would be more appropriate to lock only the major version.

pod 'AFNetworking', '~> 2.2'

The search field is slightly broken in Firefox (works but hint is not displayed, and neither is the X to clear the field).

As discussed with @alloy on Twitter I'm having issue with searching for a pod.

The network tab in Chrome's dev tools shows that repeated requests (apparently it's retrying) for http://search.cocoapods.org/api/v1/pods.picky.hash.json?query=transformerkit&ids=20&offset=0 are failing.

Also, http://cocoapods.org/javascripts/jquery-2.0.3.min.map is failing but may be unrelated.

https://github.com/CocoaPods/cocoapods.org/blob/master/data/plugins.json

his happens in multiple browsers on multiple platforms. Confirmed in Safari & Chrome on Mac and IE and Chrome on Windows.

This creates a very poor user experience if a visitor selects a platform that has no search results for the chosen platform, but did for the previous one.

I suggest we keep the platform selector above the search results as all times.

Another suggestion in relation to this is to display the number of pods found for each of the platforms inside the actual platform selector. Could improve usability.

See CocoaPods/Core#87

This is from someone who has not been to the cocoapods.org page before.

I looked around the page and I must have clicked somewhere because then when I wanted to do a search of cocoa pods I scrolled back up to the top of the page and there was no visual clue that the red "SEARCH_" text was actually an edit text field. After looking around for an editable search field I tried clicking on the red "SEARCH_" text.

I think there needs to be an extra visual clue that the search field is an editable text field. Is cocoa pods trying to mimic iOS 7 because if so that could be my problem as I don't have a device with iOS 7.

When I select a label to filter a category (name, author, summary...), all the labels get lost.

Wonder if it could be like the OS labels, just highlighting the clicked label.

When searching for "omniauth", I can't find any pods, but with "omni" I can find the SHOmniAuth pod I was looking for.

http://blog.mathieu-leplatre.info/publish-your-pelican-blog-on-github-pages-via-travis-ci.html

Which has a slot machine like cycle through a shuffled hardcoded list of pods ( we once generated a list of the most popular via search results, so we could have the top 15 in there ( plus any of ours cause I'm all into self promotion ) )

Ideally we want to make some more affordances for obviousness, there's a few options:

• Add blinking underscore
• always have a blinking bar on the left edge ( right now deselecting gets rid of that entirely )
• Add a search loupe before the cycling pod names

I have no major preference, and would be open to trying any and then re can try another and get a feel for it.

FWIW the original mockups had a loupe.

Could be implemented using the ZeroClipboard by itself, or via the jquery.clipboard plugin wrapper.

I suggest we use a simplistic icon to indicate the copy action, or follow the example of the div.os style, except display it only on hover, and with eg. a lighter background.

If you insert a : before the end of a string it won't be included and you have to hit enter before it is.

Step's to reproduce:

1. Go to http://cocoapods.org.
2. Enter OPENSSL into the search.
3. Move your cursor to the start and type PODS:.

Expected behaviour:

My search should be for PODS:OPENSSL showing just OpenSSL's result.

Actual Behaviour

SORRY. NO PODS FOUND.

Example:

Eloy D. orta: I’ve been thinking about the ~> 0.0 thing and I’m not sure it’s a good idea.
Because until v1 semver specifically states you cannot expect backward compatibility.
orta If we do '> x.y.z', we might as weel just do 'x.y.z'
Eloy D. No, bugfixes are still bugfixes.
orta so you think 1.0.0+ gets '> x.y", but otherwise we do 'x.y.z' ?
Eloy D. Ideally we would do ~> x.y.z if the version is < 1.0.0. If the version is >= 1.0.0 then it makes sense to do ~> 1.0.

I'm referring to the avatars presented in the Contributors to the CocoaPods Projects section.

We should have a nice little icon there :)

The PODS WITH SUMMARY section often displays many of the results included in the PODS NAMED section. This creates noise which doesn’t allow to see easily if there is any pod not matched by the name which might be interesting.

An implementation could be to define an order of importance (the current vertical ordering would do fine) for the various sections and just don’t display a pod if it was already included in a more important section.

otherwise you have to scroll

logos, urls, colors, font choice etc

This:
http://beta.cocoapods.org/?q=on%3Aios%20highlight
does not result in the platform toggle button to be set to iOS at the moment.

See background at CocoaPods/CocoaPods#1273. For projects that use documentation_url, this should link to the external docs, not to cocoadocs.org.

About

• Blurb about CocoaPods made in x by y, then z helped etc - 2 paragraphs
• Show Dev team, reduce the size of these maybe
• Show Sponsors logos
• Show core commiters

Will ping @andymyers / @andyrmyers
Think a great example of this is http://www.vagrantup.com/about.html

CocoaDocs does this pretty well, but doesn't scroll when offscreen.

Apparently NPM has some new cool badges, we should catchup. Badges are like emoji and are the foundation of good software.

I vote for something along the following lines

The install and docs button are separated static images were only the link is customized. Install links to a page in cocoapods.org which features with a big font and allows to copy the following line:

pod 'ObjectiveSugar', '~> 1.0.0'

The sketch file used for the preview is available here: http://cl.ly/2l0W1c2s1B2w.

Ideally this shouldn't be possible

The platform filter (iOS, OSX, etc) displays an anchor mouse pointer when hovering over the background section, however when going over the label, the pointer disappears, making it seem like its not click-able.

It's what all the web dev kids do nowadays.
And then we can use https://github.com/addyosmani/grunt-uncss which could save us a lot of download time initially.

https://twitter.com/grillitype/status/419181047956250624

Keeps them out of plain sight.

Very good work guys. The new website will be awesome. Only two suggestions while you are developing or in beta:

• expose the libraries version number on search result
• expose download number or number of people are using library (if it's possible). This is useful for new people who are looking to decide which lib is best to use.

Don't know if github issue is the right place for these suggestions.
bye
marco

I believe we should change the cursor to a pointer, just because that's how clickable things should work.

Off topic: Is there a chat or something small things like this could be discussed? I feel like that would be a nicer way for me to give my input.

Hello,

http://cocoadocs.org/docsets/GRMustache/7.0.0 returns a 404 error, even after clicking the regenerate button.

I have myself generated GRMustache reference using the last appledoc installed by homebrew, without any trouble: http://groue.github.io/GRMustache/Reference/

The cocoapods doc for v6.9.2 is online at http://cocoadocs.org/docsets/GRMustache/6.9.2/, so I guess I have introduced changes to the doc that your own appledoc doesn't like. Please ask for further information if you need any.

When searching for pods, the platform filter should remember what I've previously selected.

Awesome new site 👍

Just throwing in my 2¢ about the new CocoaPods.org:

In general, I don’t like your new design for the site. I think that the color scheme is too glaring. The current color scheme on Cocoadocs, reminiscent of the old CocoaPods.org, is much better.

In addition, the new logo is horrible. Not only does it not suggest “CocoaPods”, it also looks too small, too blurry, and annoyingly off-balance. I liked the old logo better (as currently visible on the CocoaPods org page). If you want to improve the existing logo instead of changing back to the old one, I would get rid of the bright-red background behind the “Cocoa” part of the logo, leaving everything else as-is.

On the other hand, I really like the design and functionality of the new site’s search box. I couldn’t have come up with anything better myself. Excellent!

• The organisation
• The bot

Could be useful so you can see at a glance which CocoaPods are most widely used.

e.g.:

The title doesn't fit the box.

Sometimes the darker background doesn't load and there is un-readable text:

I cannot reproduce it all the time. Looks like some kind of timing issue. Perhaps the results loads before the style? Is that possible?

• The X button when searching doesn't work in Chrome. Just try to search something, then click the X button, and it doesn't work. Works in Safari. There's already an issue with Firefox.
• Suddenly, links stop working and I have to reset the website. When I do a couple of searches, links stop responding, when I click in any button or link it just doesn't work and I have to reload the website. I know that is a little weird, I'll try to reproduce it with more computers.

On the new beta we have four options:

• Either OS
• iOS & OSX
• iOS
• OSX

What does 'Either OSX' do? I guessed that it meant "Any OS" ? . . 'Either OS' seems redundant with 'iOS & OSX'

Try searching for "Parse+NSCoding". As soon as you enter the plus key it removes it from the query, causing it to fail. Also, searching for "NSCoding" alone should return this spec, but it does not.

Able to replicate on:
Safari 6.1.1 on OSX 10.8.5
Chrome 32.0.1700 on Windows 7 SP1
IE 11.0.9600 on Windows 7 SP1

This should be on the index.

The non-active image needs to be offset the same amount.
The edges of the text feels harder too, perhaps an issue with scaling at some point?