Mike Rockett

Very cool site indeed - feels really fresh indeed. I do agree with the typing effect. May be better to have the height of those divs fixed so that everything below doesn't move down.

Thanks for the tip there - will look into that too.

I could indeed do that, but I have already implemented a templating system which gives flexibility in terms of defining plain and rich templates. Inlining CSS (as opposed to prepending a stylesheet) is a great thing for email templates, as it ensures client compatiability. So I'd like to include that specific class in SimpleForms. That said, I could look into providing the option of using your module in SimpleForms, provided it is installed. Will look into this soon. (Side note: Development of SimpleForms (and the new Jumplinks) is paused at the moment as I cannot dedicate enough time in my day to working on it. Hope to start again soon - it is still fresh in my mind.)

Great module, Martjin! And thanks for the hat-tip on Emogrifier - I can definitely make use of that in SimpleForms.

Chrome doesn't have smooth scrolling anymore... (So far as I'm aware.)

It's actually quite simple once you get the hang of it. For one, it's far less scripting in coparison to Grunt/Gulp. Right now, my NPM config for my own site in development is this: { "name": "FoundryAssetsPackage", "preferGlobal": true, "private": true, "devDependencies": { "rimraf": "latest", "mkdirp": "latest", "less": "latest", "uglifyjs": "latest", "watch-cli": "latest", "jshint": "latest" }, "scripts": { "clean": "rimraf build/* && mkdirp build/ecma build/css", "prebuild": "npm run clean", "less": "lessc --clean-css src/less/main.less build/css/main.css", "ecma:lint": "jshint src/ecma/site.js", "ecma:packages": "uglifyjs src/ecma/packages.js -o build/ecma/packages.min.js -cm --comments", "ecma:site": "uglifyjs src/ecma/site.js -o build/ecma/site.min.js -cm --comments", "tasks": "npm run less && npm run ecma:packages && npm run ecma:site", "build": "npm run tasks", "watch:less": "watch \"-p src/less/**\" -c \"npm run less\"", "watch:ecma": "watch \"-p src/ecma/**\" -c \"npm run ecma:packages && npm run ecma:site\"", "watch:all": "watch \"-p src/**\" -c \"npm run build\"", "all": "npm run build && npm run watch:all" } } As soon as you understand how to use a terminal, understanding the above is quite simple.

I'd planned on using Brunch at some point, but I feel that it is too 'automagical' for my needs. I see that it is indeed really quick, but that's not necessarily a selling point for me. And yeah, I can see how it can become confusing - even the starting from scratch docs are kinda weird. Right now, I'm not using a specific build tool - just using npm to build my assets.

I'd specifically wanted that white slide to be on its own until you continue scrolling. But have noticed a problem with that: browsers with smooth scrolling enabled by default seem to have a problem showing the menu while scroling is occuring - it takes a while to fade in. I've only seen this in Firefox, and understand that Blink/WebKit browsers don't have smooth scrolling anymore.

Ah, I thought that may be the case. As said in my previous post, I may revert. However, I'd like to do some more thinking first. I didn't intend on supporting IE<10, though I see many visitors are still using 8 and 9 on Windows 7. Adoption rate of Windows 10 is picking up here, but probably not as fast as everyone (and Redmond) would like. Would need to do some more research into the matter. If IE support turns out to be a big issue, I'll have the site use a fallback grid with the same class names - maybe overkill, but could be necessary. Autoprefixer is cool, but sticking with Lesshat for now. Thinking about a move to PostCSS, but not for this site.

Thanks for the tip of fullpage.js. Interestingly, I'd never thought of it like that - that is to day I didn't know it was referred to as mobile oriented design. Gave this a little bit of thought on my way down to the shops just now. I'm starting to think that the user experience goes against one of my busines principals, which is about sticking to simplicity. Whilst the design itself looks simple, it may not feel simple. As such, I may just revert to the normal flow. Other few ideas are in mind - will work on them through the week and into the weekend. So far, thanks for all the input everyone - very much appreciated.

I completely understand your concerns - that's why I posted this here. As much as I'm enjoying development, there are always things I tend to overlook when seeking different/interesting design principals. One of the reasons I picked this direction was because I don't want the site to look too common. Whilst that isn't always a good thing, I'm not marketing to the same people who look for common things. That said, I do still have plans to make it more user-friendly. I'm also looking at adding a one page scroller, with arrows to indicate further content. Not sure what you mean by 'fake page' effect? Yeah, I'm liking the grid. As for IE support, I am really getting tired of it - it's taken such a long time for IE to catch up. I hope Edge is doing a better job - I haven't tested it as yet (waiting for Threshold 2 before I commit to Windows 10). Will be looking further into to it to see if it's a going concern, but I don't think it will be.

Do you agree with my previous idea? Or should I perhaps show a menu without a background (and without the Foundry logo) when viewing the hero image, and then showing the Foundry logo and the menu background-color when scrolling past the hero image? Not sure what you mean about the About Foundry button - could you clarify please?

Thanks! The current site is really just a quick placeholder. There was a nice site before it, but I wasn't enjoying the development of it at the time. The menu appears after you scroll past the top of the white pane. I am thinking of making the hero image darker (with a white logo and arrow), and then using a darker menu as well. Will play around first... livecoding.tv looks cool, but I have bandwidth constraints, which is a mission for me to get around at the moment. Will stick to my little subdomain for now. ;-)

Hmm, no - I don't think so. What do you need to add to Reno? I don't understand the purpose of your request at all... And your templates having nothing to do with the admin panel...

Hi All, So I started working on my own site about a month ago. I think we can all relate to the pain behind one doing one's own site (nothing is ever perfect, frustration, etc.). That said, I'm enjoying it this time around (yes, I've tried several iterations over the last few years). Why? Because I'm keeping framework usage to a minimum, and employing my own methods to get certain things done. So, it's becoming a learning experience for me - I guess that's one of the best methods to 'open one's mind'. Anyways, I'll be keeping an updated version here: sb201510.foundrybusiness.co.za Quite liking the home page thus far. It's responsive, and I think it does a really good job at that. Far from perfect, but a good step in the right direction. Of course, I need to add a few more things to the page before I continue with the others, and then, eventually, port over to PW. Opinions and ideas are most welcome.

Hi Sradesign, Any particular reason why you would need that? I don't see the need - Reno is a fully functional admin theme. Or perhaps I am missing something here?

Hi Gazley, No, it only hooks to ProcessWire's 404 event, which fires only on HTTP requests that do not resolve to a Page. Were the old URIs from another CMS, or did you move pages around in an existing PW installation?

Module Creation: http://wiki.processwire.com/index.php/Module_Creation#Properties_to_return_from_getModuleInfo.28.29 (old wiki, but important stuff is there) Module Dependencies: https://processwire.com/talk/topic/778-module-dependencies/ Module.php (line 67) Not sure of any official [updated] module docs, actually. But haven't needed to look for them before.

You can define the PW minimum in the module info: "requires" => "ProcessWire>=2.5.5" By the way, you can also separate your info into a JSON file named <ModuleName>.info.json, like this.

I like this little module - very cool. Thanks for sharing

Looks great, @ukyo! Will be sure to give it a look-see today.

Definitely going to keep my eye on this - fantastic idea! One of my current issues with file uploads is that they expose a certain directory structure. As much as PW is protected from that, I prefer file URIs to be a little more 'process' oriented - hence one of the reasons I created little Dispo. (Speaking of Pages as records, I've been meaning to discuss the possible storage-switch from DB to Pages for Jumplinks when I rewrite... Perhaps that would make it a lot more flexible...)

Deciding to use them for projects that don't need them isn't the greatest idea, to be honest. But, for learning purposes, I would give it a try. Should you choose to do so, you could also create yourself a blueprint of sorts for use in future projects. So no, you're definitely not being lazy - if the tools are not needed, then don't use them.

Started using Gulp for a few projects several months back. It's a great tool, but found it to be a tad bulky for one of the projects. These are my current choices: Large projects: Gulp with zillions of plugins (working on one as we speak) Medium projects with a decent handful of assets: NPM Small projects with one or two scripts and one stylesheet (including PW modules): The respective ST3 plugins for LESS and Uglify Currently, this works for me. I see there are other alternatives to Gulp, but none of them give me good reason to switch over. Some alternatives boast about shorter code, but I really don't think that matters. Performance and feature-richness are what made me choose Gulp. Using NPM is also great, though not as fast. My only real quirk with NPM is on Windows. I don't particularly want to use Cygwin as I'm comfortable with my Mingw32 setup, but that means I loose several features like glob, which is essential. Nonetheless, workarounds are easy to build.

SimpleForms Alpha bumped to 0.8.0, featuring support for YAML configuration (proudly powered by symfony/yaml), in addition to JSON. You can now use a config.yaml file instead of config.json. Note that that JSON is preferred over YAML in the case that both files exist. An example YAML config file is in the default-forms directory. As you just noticed, the form directory is no longer named "forms" - it is now named "default-forms". When you install the module, the contents of this directory is copied to site/assets/forms. To me, this seems to be best-practice, considering the fact that the previous directory was wiped out on module upgrade. Lastly, you may find that, in some situations, selected fields need to be disabled when the form is rendered. For example, a "subject" field may need to be pre-populated based on a GET parameter and, therefor, read only. Often, the readonly attribute is enough, but I think disabled is better. Previously, such a field would be re-enabled after the form was processed and validation errors occurred (you may have noticed that the entire form is disabled when the form is processing). Now, these state of these fields persist by adding data-sf-disabled when the form is prepared by the front-end plugin. This makes the behaviour consistent with the intention.