Jump to content

diogo

Moderators
  • Posts

    4,314
  • Joined

  • Last visited

  • Days Won

    80

Everything posted by diogo

  1. I didn't see it overlapping on my install, only on Soma's screenshot. I saw it now, and I also like it. edit: it's definitely more elegant
  2. Ui, not easy to solve... Maybe a green button only on the Pages page, like this one in Modules... but I'm not sure... edit: the one that is now, is a more elegant solution for sure
  3. a : is missing
  4. That's why it's so funny that you named the CMS Dictator before
  5. There are two things that are bothering me. I think the + button would work better next to the title of the block instead of the bottom, and the animations feel to slow, I would say they aren't even necessary... But this is getting greater and greater. Much better than a simple pdf for sure edit: I meant only the animations for the advanced items toggle. The animations on each individual items are ok
  6. I understand that, but since the content is scrollable, to me it feels more right to have the menu always there. Not very important though, the cheatsheet works great as it is
  7. If it says explicitly that it does the same thing, can't be confusing. I would say it's good to show that people can use both. Soma, how about making the menu position:fixed? I think it might make it more comfortable. edit: Although you would have to deconstruct all the table for this
  8. I'm also undecided. For one side, would be nice to have it all translated, feels a bit strange to have some parts in one language and other parts in another. For the other side, I think that it's very unlikely that someone who doesn't understand english could build a site in pw... no documentation, no forums... hm... so, yep, makes sense to target the translations only for editors... Maybe would be nice to have a hierarchy in files, so translators can choose how far they want to go. But this makes sense only if it doesn't mean work for Ryan alone
  9. Finished the first draft of pt-pt. I still want to check again if everything is ok. http://modules.processwire.com/modules/portuguese/
  10. Glad I could help ;D
  11. they will for sure, although not exactly the same effect. nice I was thinking that it might be more difficult then I was imagining... yaaaay!!
  12. I didn't! Thanks Soma, these are very useful and I had never look at them. Ryan, couldn't they be used on the default site so people would be immediately aware of them?
  13. I also think it would be useful to use the same field type with different labels, and even having it repeated on the same template with different names. On my project, I had way to many field types for the simple task I was doing. I had something like these field types: plate1 plate2 plate3 plate4 plate5 price1 price2 price3 price4 price5 when the ideal would be having only "plate" and "price" as field types, and put them on template as many time as I wanted, naming them only there. I also had to repeat the process of choosing "type", "text formatter", "input size" and "max length" for each one of them. Would be very useful to have the option of duplicating a field, just like there is the "duplicate fields used by another template" when creating a new template. Or maybe there is already a better way of doing this and I was having unnecessary work. Is there?
  14. I'm feeling the need to have the template forms more organized to make them more readable for editors. The problem is that, it quite difficult to group pieces of information together inside the same form. I was thinking of two possible solutions for this. One would be simply dividing the form in columns, so you could for instance, on a restaurant menu, put the name of the plates on one column, and their prices on the other. The other would be dividing the fields into groups inside each page. I know we could make a page for each group instead, but in some situations I think it just makes it more complicated for the client. Those groups could be there only visually for the form, or they could even be called from the API, why not? $page->group1 could return an array of the fields inside that group. Just a very rough idea, and a very rough draft on the attachment...
  15. hm, I think Pete is right, "Content" would fit very well on the menu
  16. Well organized and easy to navigate! Well done
  17. I would also prefer it in the top right, next to the navigation
  18. nice soma! it's more practical like this.
  19. You're right. Recently I re-installed the OS and didn't change the default font on chrome... doh! It's all working fine, I get my monospaced font and I prefer it like this, with no radio buttons...
  20. I still get courier on chrome after cleaning the cache (!?) But now it's smaller if i choose monospace and bigger if i choose courier edit: But i can see you are making some changes. It's different everytime I refresh edit2: Actually, I think this choice only adds one layer of complexity. Isn't it better to just decide on a good font stack?
  21. It works on firefox! it was cached on google chrome maybe... Sorry for that
  22. hm, something must be wrong with the fonts, my default monospace font is dejavu, but i still get courier...
  23. great soma!! edit: courier is not that readable with these colors, at least in my screen. would you consider changing it to "monospace, courier;". Since this is aimed at developers i bet everyone has a favorite monospace as default in their computer. Maybe it would ruin a bit your design though
  24. if you don't find someone, why don't you choose a good company that you already know, and show them processwire. i'm sure they would learn it to win the work.
×
×
  • Create New...